Small Organizations Under Risk Management Framework, How It Scales, And Why It Matters

One of the joys of maintaining a smaller organization has always been adapting to the needs of larger organizations. After all, the larger organizations are often the ones that "create the rules" that everyone must follow. Consider a site with 1000 nodes, be it workstations, servers, or network equipment. The risks involved with that system are vastly different than the risks involved with a location of 20 or less nodes. It's this difference in scale which requires a measured and calculated approach to security. An approach that measures the risks which are specific to that location... do you see where this is going?

It wasn't long ago that we adopted RMF, or the Risk Management Framework, and it solves a lot of problems that previous frameworks had. It's designed to be a foundation that any sized organization can build upon. Below is the definition of RMF.

This risk-based approach is what enables the framework to work with both small and large sites. Each system and the associated levels of risk are considered when developing security policy. It's something that if used correctly, can empower Information System Security Managers to build a security posture that applies specifically for their environment, and ignores factors that do not.

Different Size Means Different Risks

Consider one of the largest risks to any organization- Insider Threat. Insider Threat is often considered to be the largest threat to any organization. It's why many locations often employ "separation of duties" tactics, and the idea of "least privilege." Using these techniques, you minimize the risk of an Insider Threat. These techniques are difficult to employ effectively for the smaller organization. It makes sense that a larger organization can hire a large support staff to maintain their networks and systems, and a smaller organization cannot.

What this means is that "separation of duties" and "least privilege" may not be possible to implement effectively for smaller organizations. If you only have three people, you're unlikely to be able to divide up specific roles amongst the team. It's more likely that everyone has to be a "jack of all trades"- doing a little bit of everything. Larger organizations can have multiple "shops" or "departments" which handle specific areas, such as IA, Systems Engineers / Administrators, Network Engineering teams, Developers, Help Desk, etc. Small shops don't have that luxury.

What this means is that it isn't practical to employ "separation of duties" with small teams. What you end up doing is creating "single points of failure", often compromising your operational capability for the sake of security. This is unacceptable, as Security should never compromise the ability for authorized users to use the Information System for its intended function. We create elaborate Disaster Recovery Plans in the event of an outage or disaster, and safeguards with backup recovery procedures and redundancies in the system. By this same logic, we should not allow ourselves to create single points of failure for vital roles within an organization.

Challenges For Small Organizations

Now that we have an understanding why a small and a large organization may approach "least privilege" and "separation of duties" differently, we must now acknowledge the unique risks associated with both approaches. A large location is able to properly employ least privilege and separation of duties, and is able to hire on skilled specialists in each field. A smaller organization relies more on flexible employees capable of managing several different technology areas- networking, systems administration, helpdesk, documentation, etc. I find that hiring for the smaller organizations is quite difficult, since applicants often have specific areas of expertise that they focus on.

Most of the time, people focus going down one certification track, such as Networking, SysAdmin, or Security. Having someone that delves in a little bit of everything with a high level of proficiency is rare. This means that a small organization will face challenges with maintaining a system's security compliance, or keeping up with vulnerability management. They may also face the problem I eluded to earlier- single points of failure.

When evaluating the practicality of these small teams, I find that with the increasing security requirements and considerations for Information Systems, small teams are less viable now more than ever. The increased complexity, risks, and difficulties in hiring proficient personnel mean that a smaller team comes with increased risk. Companies may be tempted to employ the bare minimum amount of personnel required to maintain a compliant system- I won't get into it here, but this poses unique problems that I may go into in another post.

Insider Threat In Small Organizations

In every environment, accountability is key. Logs are key. Non-repudiation is key. In a small organization, it is imperitive that the proper safeguards are in place to ensure that you are keeping honest people honest. Administrators in these small orgs have a lot of power and visibility regarding the information systems. It is important that proper logging and auditing is taking place since the power that a single person wields seems to scale depending on how small an organization is.

In a perfect world, you'll be able to lock off the logs so that administrators cannot tamper with them. An auditor will be able to view the logs within your SIEM of choice, ensuring the system is operating normally, and watching for any Insider Threat indicators. The risks of Insider Threat are present regardess of size, but it is important to understand the unique risks associated with the smaller environment.

Risk Management

While I often tell my co-workers that the requirements are the same in both a large and small environment, the risks associated with both environment differ. For example, in a small environment, administrators get a lot more one on one time with all the machines. There are less computers and servers, and each machine gets visibility and attention. In a large environment, it isn't unusual for machines to be left offline overnight in an office, or remain shutdown over the weekend or when someone is on leave. It's harder to put hands on every machine to ensure they are getting updates. Some may take their machines home with them, and users will hold off on applying security updates.

One benefit of a small organization is there are simply less machines to maintain. Less machines means more attention given to each machine. A shop of 5 sysadmins maintaining 300 machines may be less effective than a shop of 3 jack-of-all-trades admins maintaining 10 simply because of the scale. It's similar to how a classroom of students with one teacher and 50 students finds it more difficult to give an individual student your time vs a classroom with 10 students. The math checks out.

As a result, the risks associated with Insider Threat seem to be lower for the Users and higher for the System Administrators. This isn't always the case but in the small environments that I've seen, that seems to be true.

Why RMF Works

RMF comes with Security Controls under NIST SP 800-53 Rev. 5 which give a framework for maintaining a secure information system based on that system's specific risks. That's the beauty of RMF. You're evaluating the specific risks a system faces and developing policy and procedure as a result. It requires you to take into account all the attributes which are unique to an environment.

Without this flexible approach, you would be unable to properly mitigate the risks associated with a specific environment. RMF solves this problem by providing a framework for organizations to identify and mitigate their specific risks. It's a beautiful thing.

The last step in the puzzle is insuring that everyone understand this concept. An AO, or Authorizing Official, may be unwilling to accept certain risks due to their inherent bias towards "normal" environments and how they operate. This may not be appropriate, depending on the situation. It is important that security assessments are conducted without assumptions regarading the risks, and instead evaluate the risks inherant to each environment individually.

Closing Thoughts

While it came with a learning curve, RMF has been an effective tool for the large and the small site to maintain an effective and secure information system. By evaluating, mitigating, and accepting risk on a case-by-case basis, we are better able to adapt to ongoing changes in our industry. The flexibility that RMF provides allows us to adjust our security posture to best secure any Information System. With Cyber Security more vital than ever, it is imperitive that we are able to make these adaptations when required.