Security Management

Management is central to IT security. The central character of the management platform becomes increasingly important the more the importance of information security grows and the number of implemented solutions increases. Overview, efficiency and total cost of ownership are issues that increase the importance of integration.

Integration of management platforms makes correlation possible. This means that the information from the various systems is compared in order to adequately respond to signals, even in an automated manner. If a system is infected, remove it from the network. We are being attacked but the attacked system is not vulnerable to this type of attack. The time and energy put into IT security can be greatly decreased if these types of action/reaction scenarios take place on one platform. In addition, integration in the event of calamities can save a lot of time and thus be of great importance.

Outside of an integrated management environment, it is important that IT security efforts proceed according to a well-coordinated plan. Coordination is often difficult to achieve and deserves attention. The security and risk management (SRM) concept is a widely accepted description of how IT security should operate in practice. The desired coordination can be achieved by implementing this concept.
The 10 steps of SRM are as follows:

1. Policy. First and foremost and before any IT security steps can be taken, a policy must be established. What are the objectives of IT security and who is responsible? At its most basic level, security amounts to a comparative assessment of freedom and impediments. If the limits of freedom are unclear, or if no one knows who must make the important decisions in conflict situations, then comprehensive IT security can never be implemented. The responsibility and competencies for setting guidelines resides with managers, and this should also be the starting point on behalf of IT security. A good initial, non-technical question that can be asked is: Are we only protecting continuity with IT security or also (specific) sensitive business information?

2. Inventory. The next step is to map out which systems occur in the network. In addition to recognizing the operating system, it is also important to know which software is running on a system given that the software has vulnerabilities that are of considerable importance in IT security. And this overview must also be regularly – or preferably, continuously – kept up-to-date. For example, if you decide to install antivirus in a certain area, then the first important question you have to ask is: On how many systems? And what will we do with Macintosh systems? Without having complete insight into the systems, the policy cannot be demonstrably implemented and can therefore never provide a certain feeling of security.

3. Priorities. Priorities must be indicated within the inventory. The one system is more important than the other and will therefore also be attended to earlier in the event of risks or calamities. Which type of system is important depends largely on the business objectives. For example, clear prioritization will prevent a relatively unimportant workstation from being restored before a storage environment in the event of a virus outbreak.

4. Vulnerabilities. Detection of vulnerabilities is a continuous task that should be assigned to someone. This concerns vulnerabilities in the broadest sense of the word, thus literally vulnerabilities in software for which patches are released or something like an unsafe password. Knowing the vulnerabilities is one thing, but thorough examinations must be done to see if the systems also contain this vulnerability in the inventory.

5. Threats. In theory, a vulnerability can be very critical given that its exploitation enables immediate and full access to a system, for example. The question of whether it is actually being exploited determines the extent to which fast reaction is required. One example is when a vulnerability in the software is revealed. When the software manufacturer discloses this by releasing a patch, then the leak is not yet actually being exploited at that moment. When a third party reveals the leak and the manufacturer has to begin developing a patch, then the playing field is completely different. It is therefore also essential to keep up to date on threats.

6. Risks. By knowing vulnerabilities and threats and categorizing the priorities of systems, it is possible to determine an organization’s risk level. The risk level determines how fast action needs to be taken.

7. Security. By knowing the vulnerabilities you can determine which security steps need to be taken and on how many systems. This can entail a configuration change, an update or additional technology. In the last case, the absolute value of the preceding steps is that a thorough count can be made as to how many systems need the extra technology and for how many of these systems this technology must therefore be acquired.

8. Enforcement. Acquiring security or designing a configuration change is one thing, but these steps must also be enforced. What is important here as well is that there be a clear path for making exceptions. If a certain software cannot or may not run on a certain system, who will authorize an exception for this system?

9. Evaluation. After enforcement of security comes the evaluation: Did the implemented measures have the intended effect? In other words, was the ascertained risk eliminated? This largely concerns reporting and analysis, but it can also mean that a real test is conducted to see whether the found vulnerability can really not be exploited any longer.

10. Compliancy. This last step serves to demonstrate compliance with the established policy. This is not only important for internal objectives but also for showing to external auditors.

All of these steps can result in a revision of the original policy. This is why SRM is always illustrated as a circle, which indicates the cyclical, continuous character of IT security.