* Leave your work in the workplace! *

So, the hard way to review the creation of a brief overview of NIST SP 800-53 comes to a logical end. I am glad that I managed to accomplish this and write a cycle of articles, albeit small but complete in content, without stopping at the first or second part. In the future, I hope, it will turn out to share with the public my own thoughts on the subject of information security, IT and auditing.

So, this article will finally discuss the selection of a set of security controls, fitting it to the needs of a particular organization and creating so-called “overlays” overlaps applicable beyond the scale of a separate organization.
')
Links to previous articles:

IB in American. Part 1. What is NIST 800-53 and what do security controls look like?
IB in American. Part 2. Is it possible to learn more about NIST 800-53 and where does risk management go?
IB in American. Part 3. What is a basic set of security controls and how to determine the criticality of information systems?
IB in American. Part 4. We deal with the "fit" and "overlap" and complete this review.

Selecting a base set of controls

In the previous article, I presented my vision of the methodology for determining the criticality of IP presented in the FIPS 199 document and carried out in the first step of the Risk Management Framework discussed in the second article. What to do next?
After determining the level of criticality of the IP, the process of determining the necessary safety controls begins. The first step is to select a base set of controls based on the results of the categorization. One of three sets is selected, corresponding to a low, medium and high level of severity. Of course, it is worth noting that not all controls are included in these sets. Least of all they are represented in the set for the low level, which is obvious. Once again I dare to remind you that the basic sets are only the starting point for the further process of creating a suitable set of controls. Further, in the process of “fitting,” controls may be added, removed or refined to meet the organization’s security requirements.
Also important is the fact that, due to its universality, the basic sets presented in the document have certain assumptions within which they are relevant. In other words, these sets were created for specific, very specific conditions of use. However, do not blame the authors for their narrow views, because these conditions are specially chosen in such a way as to cover the most massive segment of IP. So, I present to you these assumptions:

1. IP are located on physical objects ( initially the sets are not sharpened for virtualization );
2. Information of users in an organization’s IP is relatively constant ( users do not create or destroy information in significant quantities on a regular basis );
3. IPs operate in multiuser mode;
4. Some user information in the organization's IP is not available to other users who have authorized access to the same IP ( after all, access control is a basic principle, isn't it? );
5. ICs exist in a network environment;
6. IP are essentially general-purpose systems ( i.e., we are not trying to protect Iranian uranium enrichment centrifuges );
7. The organization has the necessary structure, resources and infrastructure for the implementation of controls.

If some of these assumptions do not correspond to reality - it is necessary to make an additional “fit” of the controls to the needs of the organization (which will be described in detail below).

The authors also present a number of possible situations that do not overlap with protective measures implemented in the basic sets of controls:

1. There is an insider threat in the organization ( as they say, “there is no reception against scrap” );
2. With regard to the organization, there are constant threats from serious violators ( for example, we are talking about the banking sector );
3. Certain types of information require additional protection in accordance with the requirements of the law, regulators, etc. ;
4. IP should interact with other systems through environments with different levels of security ( for example, through a public network segment ).

If any of these assumptions are correct for the organization, then it is necessary to refer to a set of additional controls and “fit” the protective measures in accordance with the results of the risk assessment in the organization.


* Santa can rest ... And you are not! Security has no holidays *

"Adjustment" of basic sets of controls

Recall that “tailoring” refers to the process of optimizing, refining or improving a set of controls in such a way that it meets the security requirements of a specific IP or organization. This activity is usually carried out after selecting a base set of controls and includes:

1. Identification and characterization of general safety controls in the basic set (here we mean the type: general / system / hybrid);
2. Analysis of possible applications of the remaining controls of the basic set;
3. Selection of compensating safety controls as required;
4. Setting the values ​​of security controls already defined in the organization;
5. Supplementing the base set with additional controls and “reinforcements” of controls if necessary;
6. Providing additional information on the implementation of controls, if necessary.

The “fitting” process, which is part of the selection and specification of controls, is part of the risk management process used in the organization. In essence, an organization uses a “fit” to achieve cost-effective security, based on risk assessment and contributing to meeting business needs (after all, no one needs information security that is not capable of covering current threats or the cost of which exceeds potential losses). All activities on the "adjustment" of controls should be mandatory coordination with the responsible persons appointed in the organization before they are implemented.
In general, the fitting process occupies one of the central places in this publication and is described in great detail, since it is one of the fundamental activities contributing to the construction of an IS system that meets the needs of the organization and mitigates current IS risks. Perhaps in more detail this topic will be covered later.


* Security is a must care at any time of the year *

The development of "overlays" ("overlays")

So, briefly familiarizing yourself with the process of “fitting” basic sets of controls, which provides the possibility of obtaining more accurate and relevant information security measures, you need to turn your eyes to another very useful possibility of applying the NIST SP 800-53 publication.
In certain situations, it may be beneficial for an organization to use the “fit” tool to obtain a generalized set of controls, referred to as “overlap”, applicable across an industry, or, for example, necessary to meet specific requirements, technologies or performance objectives ( hereinafter we will call such "overlaps" industry). The development of such a kit can be carried out both by the organization itself and by federal authorities within an industry. For example, the government may issue a set of controls that are mandatory for implementation in all federal institutions where the use of the PKI infrastructure is carried out. Thus, a set of security controls can be developed by any interested person to adequately respond to information security risks and then distributed to other industry participants or users of any technology or equipment. This feature of the “fitting” methodology provides a good basis for providing standardization of information security capabilities in various technological areas or in specific operating conditions (the universality and uniformity of the approach laid down by the authors in the very foundations of the NIST SP 800-53 publication apply).
The concept of "overlaps" is introduced to enable the development of both industry-specific and specialized sets of compensating information security measures for information systems and organizations. An “overlap” is a fully defined set of security controls, “reinforcements” and additional information on their implementation, developed in accordance with the rules of the “fitting” process.
“Overlaps” complement the basic sets of security controls by:

1. Providing the ability to add and remove controls;
2. Ensuring the applicability of security controls and their interpretation for specialized information technologies, computer paradigms, types of information, execution environments, technology industries, legal and regulatory requirements, and so on.
3. Installations in industry-wide values ​​of safety control parameters and “gains”;
4. Expansion of additional information on the use of controls if necessary.

Usually, organizations use “overlaps” in case of discrepancies with assumptions, within which basic sets of security controls are created (we already talked about these assumptions earlier in the appropriate section). If the organization does not have significant differences with the assumptions of the basic sets, more often than not there will be no need to create and use "overlap".
“Overlaps” provide an opportunity to achieve unanimity within an industry (in other words, areas of interest) and develop a security plan for an organization’s IP, which will receive support among other participants, despite the specific conditions and circumstances in a particular industry. Overlap categories can be useful for different areas of interest, for example:

1. Industrial sectors, coalitions and corporations (health, energy, transport, etc.);
2. Information technology / computer paradigms (cloud services, BYOD, PKI, cross-domain solutions, etc.);
3. Functioning environment;
4. Types of IP and modes of operation (industrial / test systems, single-user systems, weapon systems, isolated systems);
5. Types of tasks / functioning (counterterror, emergency response, research, development, testing, evaluation, etc.);
6. Requirements of legislation and regulators (here the US requirements are not applicable to us).

When developing overlaps, the authors of the publication advise to use the risk management concepts incorporated in NIST SP 800-39 to achieve greater efficiency. Successful development of "overlap" requires mandatory participation:

• Information security professionals who understand the specifics of the field, which is the purpose of the development of "overlap";
• Experts of the subject area for which the development of overlapping is carried out, having an understanding of the essence of safety controls, the assignment of basic sets of controls and the structure of the development of "overlaps".

Several “overlaps” can be applied to one set of controls. The “tailored” set of controls obtained as a result of the development of the overlap can be either more or less resistant (strong) in relation to the original one. Risk assessment helps determine whether the risk of implementing a “fit” set is acceptable as part of the risk-taking strategy adopted by the organization or the “area of ​​interest” that developed the overlap. In the case of the introduction of several “overlaps”, the situation in which different overlaps contradict each other in separate moments is not excluded. In the event that such a contradiction is found, which can lead to conflict in the implementation or even rejection of any specific security controls, the controversial situation should be resolved with the involvement of responsible persons, floor developers, information owners and business.
In general, “overlapping” is intended to reduce the need for “fitting” sets of controls on the go (in haste), by developing a set of controls and “reinforcements” that best meet specific conditions, circumstances, and / or situations. Thus, a more mature and in the long term uniform approach to ensuring information security should be achieved. At the same time, the use of “overlaps” does not obviate the need to make further “adjustments” to meet the needs of the organization, the restrictions and assumptions in force in it. The "fitting" of the "overlap" is also allowed and is done with the approval and approval of the responsible persons and developers. However, in the general case, the expected amount of changes in the structure of security controls sets that are being carried out in a hurry is significantly reduced.


* Ignoring safety, you walk on thin ice *

Documenting the selection process of controls

In NIST, of course, there is also a section devoted to documenting all actions carried out in the process of working with security controls. Of course, Americans are noble bureaucrats and, like the workers of many domestic institutions, love to back up any activity with some piece of paper. However, this time we are still talking about expedient things.
So, it is necessary that all decisions on the choice of controls are accompanied by the argumentation of the decision made. This is necessary to facilitate the success of subsequent assessments of potential threats to the assets of the organization. The final set of security controls, including any restrictions on the use of both individual information systems and their combination, should be reflected in the appropriate security plan. It is necessary to ensure that any significant decisions are documented as part of the risk management process, in order to provide access to this information in the future to responsible persons.

Additional findings

Decisions made in the process of “fitting” sets of controls do not exist by themselves, but in the context of a particular organization. And this means that while they are focused on ensuring information security, it is necessary to ensure the consistency of these decisions with other risk factors existing in the organization. Factors such as cost, schedule, performance, should be considered during the definition of controls that are planned for implementation in the organization.


* Security requires attention to detail *

New developments and inherited systems

The process of selecting security controls described in this article can be applied to information systems of an organization with two different approaches: as inherited systems or as new developments.
For systems being developed, the process of selecting security controls is made from the point of view of “determining requirements at the design stage”, since the system does not yet exist in final form and only the preliminary categorization of the information system is carried out. In this case, the controls included in the information system security plan serve as security requirements and are included in the system during the design and implementation phases. For the rest, the full RMF cycle is simply applied.
For legacy systems, by contrast, the selection process for controls is made from the point of view of gap analysis, when an organization plans to make significant changes in the information system (for example, during an update or modification). Since inheritance means that the IP is already in use, the organization most likely has already categorized the system and selected security controls will result in adjusting the previously selected set of controls that should already be present in the agreed security plan for the system and the subsequent implementation of these controls in the IS. Therefore, gap analysis can be performed as follows:

1. Confirmation or updating of the criticality value and levels of negative impact on the IP is carried out on the basis of information that is currently being processed, stored or transmitted by the system;
2. An analysis of the existing safety plan describing the implemented safety controls is carried out. Any changes to security categories, negative impact levels, and other changes in the organization, business processes, systems, and operating environment are taken into account. A reassessment of risks and a safety plan is mandatory, as well as the documentation of any additional safety controls that must be implemented in order for the risks to remain at an acceptable level for the organization.
3. The implementation of the controls presented in the updated security plan is being implemented, as well as the documentation of the action plan and the key points of the controls not implemented.
4. The steps presented in the Risk Management Framework cycle are also carried out in the same manner as for newly developed systems.

Instead of conclusion

On this, perhaps, you can finish the review of the publication NIST SP 800-53. Outside this series of articles there are still a lot of interesting, because the document contains more than 450 pages of printed text. However, it is not possible to get acquainted with all the details and subtleties of using this document in 4 short articles on Habré, especially without the experience of actually applying the principles presented in the document and the implementation of the described controls.
I hope that I managed to interest someone with the publication of NIST SP 800-53, and for those who have already heard something about it, tell a little more about its structure.
And finally, another poster:

* Add a pinch of security. This is the key ingredient! *

For this I say goodbye. If you have questions, comments and suggestions - do not hesitate to use comments and PM.
Thanks for attention!