Today we continue our look at a series of practical steps that districts can use to increase their NIST compliance. Looking at the complete set of NIST controls can be a daunting experience. One of the best ways we have found to make these cybersecurity improvements more attainable is following the CIS Controls Top 20 list, which maps nicely over into NIST. CIS also breaks their controls list into three implementation groups, in somewhat of a "start here" group 1, a more "advanced" group 2, and when that's done for full "Ninja status," move to group 3. This series is going to focus on a walk-through of the "start here" group 1 items.
Today's topic comes from the control group focused on limiting risk by controlling access to your network's specific resources. These controls are ultimately going to require that your organization put in place “the processes and tools used to track/control/prevent/correct secure access to critical assets (e.g., information, resources, systems) according to the formal determination of which persons, computers, and applications have a need and right to access these critical assets based on an approved classification.”
The full control set is far from a trivial topic to implement, but the implementation group 1 (IG1) requirement for this control group once again has just a single action item:
Action item #1 - Protect Information Through Access Control Lists - Protect all information stored on systems with file system, network share, claims, application, or database-specific access control lists. These controls will enforce the principle that only authorized individuals should have access to the information based on their need to access the information as a part of their responsibilities.
Many of you who are network infrastructure savvy will recognize the concepts of an access control list (ACL). Eventually, as your security posture matures, we will be talking about adding internal network ACLs to your security implementations. We will use the concept of access control "list" in a more general sense for this discussion.
This control speaks about file share security rights and even basic login rights to various systems, applications, and databases. It's asking that you continually and deliberately review the information stored in your systems and that those who are permitted to access said information require that access.
Most of us probably are doing a pretty good job of access or login credentials, at least at the front end. We don’t hand out IDs to people that don’t need them. But what about our process for removing access when no longer needed? Is that process just as good?
And what about our file share rights structures? Any chance they are too broad or too open from a security perspective? Do all teachers need access to all student data? The more available access the greater the risk. Of course, like all security controls, it's a balance of function against risk.
Successful implementation of this control requires a deliberate process to identify the data in your systems, making a formal judgment on who needs access, documenting those judgments, and then following through to the technical procedures to enforce those decisions.
If you need assistance with a process for evaluating access and developing the tools and strategies required for effective controls, reach out to our team. We will be happy to help you get started.
-Bob Knapp |
You must be logged in to post a comment.