The One-Laptop Security Department

9 min read

Hats. We all have many, but for a small business owner you wear them all at the same time. This includes running your Security Program (unless, and you should, farm work out to an External Service Provider).

CMMC isn’t a framework or a standard. You need a program. A one person company does not need an enterprise security department. Instead as a founder you need a routine. All programs need routines to run.

Products Do Not Implement Controls

Microsoft Defender can find vulnerabilities. Huntress can monitor security events. Intune can enforce device settings. A FedRAMP provider can protect its cloud infrastructure. An MSP can review alerts.

None of those tools decides how your company operates.

Someone has to decide who gets access, which software the company allows, when vulnerabilities require action, what happens after an alert, and when a business change affects the CUI boundary. Wearing your security officer hat you need to turn technology into procedures.

You do not need to create 20 Standard Operating Procedures. We want to identify the small number of things our founder must actually do and later write those actions directly into the SSP. Creating wave after wave of documentation will lead to problems for a small company. Document drift will cause you to fail assessments.

Instead treat your system security plan as a top level document that describes your plan for system security. Almost like it is in the name, or something. You will need some procedures and artifacts documented, especially inventory. Basically write down things you need to do your business. Put all your security related stuff in your SSP.

Think in Rhythms, Not Departments

A one-person security program works better when you divide the work into four buckets:

  • things the technology does continuously,
  • things to review on a schedule,
  • things to do when something changes, and
  • things to do when something goes wrong.

That gives us a security department without creating a security department.

What Happens Automatically

Start with the work you already paid someone else to do.

Defender continuously evaluates the managed Windows endpoint for vulnerabilities and malware. Intune checks whether the laptop still meets the required configuration. Huntress monitors for suspicious activity. The cloud providers generate authentication, access, and file activity logs.

Do not recreate these technical processes manually. In your SSP explain that these requirements get inherited. You just need to make sure the services remain active.

Automation performs the check. The company remains responsible for the decision.

If Defender finds a vulnerability, Defender has done its job. The control still requires someone, you (or your MSP that you really should hire), to decide what to do about the finding.

The Weekly Security Routine

For a one-laptop company, start with one scheduled security review each week.

Pick a day. Put it on the calendar. Treat it like bookkeeping.

You or your MSP reviews (in our example architecture):

  • Defender vulnerability findings,
  • security alerts,
  • Windows and application update status,
  • Intune device compliance,
  • failed or unusual sign-ins,
  • Huntress alerts or reports, and
  • outstanding remediation items.

The review does not need to become a three-hour meeting with yourself. Most weeks, nothing interesting should happen. Feature, not bug.

You check the dashboards, handle anything that requires action, and record that the review occurred. If an MSP performs the review, you review the MSP report and follows up on anything that requires a business decision.

Now we have turned a large collection of NIST requirements into a simple habit:

Once a week, check the health of the one system that can touch CUI.

Vulnerability Management Means Running More Than a Scanner

Defender, using the E3+P2 license in our model, can continuously identify vulnerabilities on the laptop and supported applications. That solves the technical scanning problem.

You still need to spell out a process in your SSP on how to handle a vulnerability when spotted.

When Defender identifies a vulnerability, the founder or MSP reviews the finding, determines whether it affects the system, applies the update or mitigation, and verifies that the vulnerability no longer appears.

The company also needs to react when a new vulnerability appears between scheduled reviews. A Microsoft advisory, CISA notice, Huntress alert, or software vendor warning may trigger another review.

The procedure remains simple:

Find it. Decide what it means. Fix it. Verify the fix. Keep the record.

That sentence will eventually become much more valuable in our SSP than a paragraph that says, “See Vulnerability Management Policy.”

You can write directly in the SSP how you Find it. Decide what it means. Fix it. Verify the fix. Keep the record. Keep your documentation lean.

Access Control With One User

When a small business owner opens up NIST-SP-800-171 for the first time they get overwhelmed reading 3.1.1.

Many access-control requirements sound complicated because large companies need to manage hundreds or thousands of accounts. You only have one authorized CUI user.

The 1099 contractors do not receive CUI access. Their BYOD devices cannot access the CUI repository. Their Government-Furnished Equipment does not connect to company systems.

What you need are multiple identities with your multiple hats.

Access Control specifically calls for separation of duties and least privilege. Feels like an oxymoron for a one person company.

Under NIST-SP-800-171 different identities can be defined by roles. Give yourself a normal account for daily work and a separate privileged account when administrative access becomes necessary.

Microsoft already made you buy enough roles to do this. Just enforce this on your laptop. Have one user to change and update stuff, and your everyday user to do stuff.

Then once a month review your accounts and access to confirm a bunch of new users weren’t added or changes weren’t made without approval.

The review should take less than a half hour.

You need to examine the user list, privileged accounts, and file-sharing permissions. You have a small scope, make sure to create small repeatable procedures.

Change Control and the Single Computer

When you read the configuration management requirements for approving changes a single person company can get frustrated. It seems like overkill.

You do not need to form a Configuration Control Board every time you want to install something new.

What you need in your procedures is something that ensures you:

Do not install or change software without considering the security impact first.

Before adding software, you need to document what the company needs, why the company needs it, whether the vendor supports it, whether it creates a new cloud connection, and whether it changes how CUI flows.

You can make a form, send yourself an email, use a spreadsheet. Even paying for a ticketing system has value for a single person company. Having everything organized in one place with little effort can be worth the money.

After installation, you verify stuff works, close the ticket.

You must document:

  • what changed,
  • why it changed,
  • when it changed,
  • who approved it, and
  • whether the change affected the system boundary.

You need traceability.

A ticketing system is something I encourage every company to have. If you want to use Microsoft Forms here are instructions.

Some Events Require Immediate (up to 72 hours) Action

Scheduled reviews handle ordinary operations. Certain events should trigger immediate action.

Examples include:

  • Defender or Huntress reports a serious security event,
  • you lose the laptop,
  • someone sends CUI to the wrong system,
  • a new vulnerability creates an immediate risk,
  • the laptop falls out of compliance,
  • you detect malware,
  • someone attempts unauthorized access, or
  • you suspect that CUI may have left the approved boundary.

Having an MSP can help the single person shop handle these events.

Later in the SSP, we can spell out the exact steps.

For now, the founder only needs to understand the principle:

Routine problems follow the routine. Security events interrupt the routine.

Business Changes Can Become Security Changes

Some of the most important security events do not look like cybersecurity events at all.

You might hire another employee. A contractor suddenly needs access to CUI, or you buy another laptop. Maybe your Prime wants to change the file-transfer process.

Those requests may sound operational, but they can change the CMMC boundary.

Our founder therefore needs one more procedure:

Before changing who can access CUI, where CUI can go, or what technology can touch it, stop and review the scope.

We introduced this as a scope-change trigger in Post One.

Now it becomes part of normal security operations.

What Must I Do for CMMC Compliance?

When we strip away the product names and compliance language, the one-laptop security department has a pretty short job description.

When Founder or MSP Action
Continuous Security tools monitor the endpoint, identity, and authorized services.
Weekly Review vulnerabilities, alerts, compliance, updates, and outstanding remediation.
Monthly Review accounts, access, authorized software, and major configuration changes.
When software changes Review the security impact, approve the change, verify the system, and record the change.
When a vulnerability appears Review it, remediate it, verify the correction, and keep evidence.
When a security event occurs Contain the problem, investigate it, escalate when necessary, and document the response.
When the business changes Check whether the change affects the CUI boundary before implementing it.

That starts to look much more manageable than “implement 110 security requirements.”

The MSP Can Do Work, but the Founder Still Owns Decisions

A founder who wants to spend very little time on IT can pay an MSP to perform most of the weekly review. A managed VDI provider can take even more technical work off the company’s plate.

That does not remove the founder from the security program.

A good small-business security program separates technical work from business authority. You can buy as much technical work as makes financial sense, but you always own the business decisions.

Keep Evidence While You Work

Do not wait until the CMMC assessment and try to recreate the last year of activity from memory.

Make evidence a side effect of doing the work.

This will save a small company an enormous amount of time and money.

A weekly vulnerability review creates a review record. An Intune check creates device-compliance evidence. A Defender finding and later clean scan create remediation evidence.

If you are going at it alone how can you ensure you follow the evidence collection needs?

What We Just Built for the SSP

We now have enough information to start writing actual operating procedures into our SSP.

We know:

  • who reviews the security environment,
  • what tools operate continuously,
  • what the founder reviews each week,
  • how the company handles vulnerabilities,
  • how the company reviews accounts and access,
  • how the founder controls software changes,
  • what events trigger immediate action,
  • what business changes trigger a scope review, and
  • what records those activities create.

Notice what we did not create.

We did not write a separate Vulnerability Management Plan, Access Control Plan, Configuration Management Plan, Security Operations Procedure, and five other documents just to explain how one person manages one laptop.

We described what actually happens.

As a small business focus on doing the do and let the residuals of work prove the procedures in your System Security Plan.

↑