Notes on NISTIR-7621

Overall Analysis

NISTIR-7621 Revision 1 is generally sufficient as a framework for small business information security; although a bit dated, many of its points are still applicable to today's information security landscape. NISTIR-7621 does have some failings: some of its information, especially the more detailed recommendations given, are at times outright wrong or reduce security posture in a organization. Despite occasional failures around detailed information, the recommendations in general are quite good and mostly applicable to someone with a growing small business who lacks technical knowledge surrounding information security.

Section Breakdowns

(1) Background: What is Information Security and Cybersecurity?

Omitted as its a simple summary and rationalization as to why the document exists in the first place, largely irrelevant.

(2) Understanding and Managing Your Risks

The writing of managing risks as action items is a great approach, and it would be fantastic to see other documents follow the approach found within this section. A small business owner could read the section and immediately begin applying it to their circumstances. The document also gives a clear, concise, framework to begin an information audit, a core procedure for information security. If you don't even know what you have and the value of those items, how could you even begin to manage anything? Better yet, the document provides clear resources to leverage in the case they need assistance. Many frameworks toss readers to the wolves with general statements or steps, but no way to get help where one's knowledge fails. Clearly identifying resources like the local Chamber of Commerce or Federal Trade Commission increases the likelihood of a successful information audit.

(3) Safeguarding Your Information

The recommendations stated for the session lock feature when a computer is idle sounds good on paper, but are impractical and likely harmful. (Page 22)
- Now, locking the session after idling for a while is a good idea, but the given example idle lockout is "2 minutes" — this is much too short a time window for an idle user. From personal experience as a Systems Administrator, allow me to cast down enlightenment on session locks: do not pick a super short idle window. Why? Because users are too clever for their own good. The 2 minute window given as an example from CISA will almost certainly lead to something like the following scenario: Lisa the accountant shows up to work after the session lock policy was implemented the night before. She ends up on a phone call or other work at her desk without touching her computer for a few minutes. The computer locks. Lisa gets slightly annoyed. Lisa unlocks the computer. Later, she does another task that causes her session to idle. The computer locks. Lisa gets a tad more annoyed than the last time. Lisa unlocks the computer. And on and on that will go until Lisa has a brilliant idea if her complaints on the session lock are ignored: get a mouse jiggler or an equivalent way to defeat the idle detection. Now with the jiggler installed she no longer has her user session lock; then she gets up for lunch one day and somebody else walks up to her now unlocked computer and copies the entire business's account sheets. Unfortunately, that was not a hypothetical story, we truly had that occur to one of the firms we managed systems for.
"Set the wireless access point so that it does not broadcast its Service Set Identifier (SSID)." (Page 26)
- This is useless. The SSID being "hidden" was originally a bug in the first spec from the IEEE. Basically when the SSID was left as NULL, many client programs would not display the network. Later on this became more standardized via SSIDExtensions where a "hidden" flag could be set. This is all well and good, but does absolutely nothing from a security standpoint. The network still allows clients to connect and an attacker's scan will trivially pick it up. On top of this, many modern operating systems, mobile and not, now display "hidden" networks in their network selections as "Hidden Network". Hiding a wireless network is pointless for security — it only adds difficulty to legitimate users attempting to connect and does not stop any attacker from picking it up in a scan.
"Set your router to use WiFi Protected Access 2 (WPA-2)..." (Page 26)
- WPA-2 is now considered a legacy protocol. The new version is WPA-3. WPA-2 is susceptible to quite a few vulnerabilities at this point in time, like [Key Reinstallation Attacks], see [https://www.krackattacks.com/]. The guidance should be to target WPA-3 if WPA-3 is possible given the network requirements (many IoT devices only support WPA-2).
  
  Whatever solution you apply on the user's session it cannot, under any circumstances, be unduly bothersome. The user is smart — they will find a way around security controls if they're irritated enough. NISTIR-7621's guidance would be better served with reasonable timeout like 10 - 15 minutes, or, even better and the solution we eventually implemented at that firm, have a camera do user presence detection when they're at their desk and auto lock the session when leave their workstation.
Advice for backups (Page 31 & 32)
- This section still largely follows best practices today. They mention that backups should be stored in different places and go on to list three different places which follows the 3-2-1 backup rule per CISA "Data Backup Options". Furthermore; a recommendation is made to test the backups periodically; this is a oft-ignored step — if you can't validate a recovery strategy, then the strategy should be treated as though it doesn't exist.
- Some things that are missed though:
  - Instead of stating "You may want to consider encrypting your backups" (Page 32), it would be better to have a firm stance and instead state "All backups should be encrypted when created". Backups, if created correctly, will almost certainly contain sensitive information including customer information and with the rise of privacy laws locally and abroad like the General Data Privacy Regulation in Europe, not having proper encryption of sensitive information can lead to regulatory compliance issues and even fines.

(4) Working Safely and Securely

Overall items

No mention of centralized system controls
- If a small business has more than a handful of employees it becomes increasingly difficult to manage those user accounts and, more importantly, handle auditing and legal compliance. When a small business owner reads that, most will think of having a local admin account which they then use to create their individual employees' accounts under that local admin. Now, the individual tools do not need to be mentioned, but centralization of system controls should be discusses. It's a core requirement of audit able systems, especially if you have to do legal discovery. This was some of the work and consulting I helped local businesses in Austin, Texas with when I worked as a Systems Administrator.

7.0 KiB Raw Blame History