OTPs as Second Factor
It is of vital importance to screen the development of new or the further development of already existing services, applications or IT-infrastructure for existing vulnerabilities or risks. This is even more important due to the fact that there is critical information and data involved.
In dynamic environments such as today’s companies there’s a number of important applications, services and a lot of infrastructure, that can’t be monitored so that every vulnerability and every risk can be systematically catalogued.
This might be due to the fact that an IT-environment is subject to various influences:
This pressure leads to the following unfortunate situations: Security that requires special care due to the momentum and complexity of it, is being ignored or neglected.
In IT, you suffer acutely under the everyday misgivings of the field and not directly under the latent vulnerabilities that might maybe arise in an unknown future.
This momentum can turn out to be too much of a challenge one some occasions and lead to the IT-department turning into some sort of maintenance crew, that tackles daily challenges and implements half-solutions in order to deal with the pressure even if it only treats the symptoms and not the illness itself. This behaviour open doors for new vulnerabilities and risks. Often, this behaviour is even accompanied by some sort of wishful thinking along the lines that it will all work out somehow because, thus far, it has always worked out somehow.
Instead, it would be useful to seriously incorporate security into the planning of projects and other ventures. An efficient tool to get a good overview of the complex affair that is security as well as project planning are Security Concepts, which I will talk about in this article.
A security concept is a clear and targeted analysis of information systems or an application, a service or parts or all of the IT-infrastructure. It documents the requirements in terms of security as well as its goals, the implemented security architecture and all relevant security configurations as well as processes that aim to manage and observe the security of the solution that’s being described. Furthermore, it contains a systematic analysis of risks and vulnerabilities and a documentation of the measures necessary for the treatment of the identified vulnerabilities and risks, including responsible operatives and scheduled dates.
The security concept should be an obligatory object while tackling projects that touch the IT-environment of a company: The implementation and restructuring of new applications, technologies, services and so on… as well as changes of the already existing IT-architecture, network technologies, interfaces and in every case, where the flow of information and data is being altered (this includes outsourcing-projects that see third parties enter the equation). This means that there must be a sanctioned off security concept before a system is being implemented. h1. Goals
The security concept aims to give an overview in terms of speciality, conceptionality and security.
It should be a stringent, self-contained document which can be consulted at any given time in order to be able to reconstruct and follow the thoughts behind security thoughts and measures that are necessary for a specific solution. It shows the risks and remaining risks of the implementation of said solution. It is also well suited to ease the workload put on auditors and internal revisers, because it shows and explains the situation as well as the relevant arguments pro and contra potential measures, vulnerabilities and risks.
The security measures in an IT-environment are being defined according to their requirements, which will reflect in the realization and keeping with the definitions set once the solution is realized. Unnecessary effort and security gaps are made nigh-impossible.
The security concept should remain as flexible as possible, though, consisting of modules that can be applied depending on the place where they’ll be deployed when needed, depending on whether the solution is an abstract and conceptual analysis or a single application.
Generally, there should be a basic framework for the construction of a security concept, which has chapters that can be skipped, should the final concept require it. A simple basic framework could look like this:
|Description of the situation/Scope||Even the title of the concept describes the content of it (avoid abbreviations and acronyms). General intentions, plans, use, goals, naming of the owners and other responsibilities|
|Borders||Borders, restrictions, framing conditions, dependencies|
|Targeted security goals||What is to be protected from what? Which factors must be paid attention to (confidentiality, integrity, availability, non-repudiation, liability, authenticity, operational security…)|
|Technical-conceptional description of the system and solution with clear illustrations||Overview of the system, the infrastructure in use, rough system-architecture (including locations), system descriptions, requirements, functions, sequence of events, components, parts of the system, configurations, communication matrix, interfaces (technical, organisational, external, internal…), schematics|
|Definition of assets and protected objects||Informational or data objects (i.e. personal or financial data of a company, customer data, mandates, HR…), end user services (application functions and processes), software objects (application software), system and physical objects (hardware, software that is close to the infrastructure and OSes)|
|Analysis (risks or vulnerabilities: informal, detailed, combined)||The risk analysis or vulnerability analysis is a central element, damage and risk assessment (aka. Vulnerability assessment) as well as the delegation and classification of adequate security measures. For the definition of the requirements regarding the measures in a security concept, the following information needs to be provided: Risks and generic security measures (security standards, basic protection, ISO, Cobit and other frameworks), data classification, laws, policies, guidelines and standards, technical and organisational requirements|
|Measures to be taken including description||Description of technical measures, organizational measures, basic organizational measures, sequential measures, access concept|
|Residual risks||Listing of residual risks after the implementation of the measures.|
|Binding planning of implementation of measures||Responsibilities and deadlines for the realization of the measures, responsibilities for the maintenance of the measures, surveillance of use/cost of the measures|
|Controls||Reviews, auditing etc.|
Important security principles must be paid attention to as well, always keeping the question in mind whether or not they are applicable to the current motive:
|Informal approach||Using the informal approach means that you assume that gaps in security can be spotted without looking too closely. They are obvious. There are no guidelines when it comes to compiling a list of risks. The documents as well as the methods used to research said documents are based on individual decisions that the situation calls for. The advantage of this approach lies in its simplicity (the disadvantages are the possibility of not seeing the hidden risks and the lack of structure. You’re dependent on intuition. Even if people can rely on their gut feeling more often than not, this intuition has to be less emotional intuition and more intuition born of experience). However, this un-reflected approach can lead to it being seen as a capitulation of sorts when facing a complex IT-context. An adequate dealing with the analysis is not a given with this lackadaisical approach.|
|Baseline approach||In this approach, you are going on the assumption that risks are spread out evenly over the area of analysis that you’re focussing on. This strategy relies on the insight, that known and established standard products are being deployed, which can furthermore be adequately secured by using a standardized set of measures. The advantages of this approach are in the quick realization, its standardization and its simplicity. However, basic assumptions are seen as the factual truth in this approach. This means that before this approach is implemented, knowledge predating the measure should be checked for its veracity. In fact, knowledge must always be checked for veracity and applicability to the current situation.|
|Detailed analysis||Opposed to the informal approach, the detailed analysis looks not just at the obviously visible vulnerabilities but also those that have to be researched and looked at in great detail. A great help to achieve the desired level of detailed information in order to spot and treat these more hidden vulnerabilities is a structured methodology. The advantages of this approach are its high attention to detail. The disadvantages lie in the high cost needed as well as the long periods of research that are needed to get to all the details.|
|Combined approach||The combined approach differentiates between bigger and smaller risks, whereas both kinds are to be treated adequately. To tackle the smaller risks, maybe the baseline approach suffices. The bigger risks must be looked at using the detailed risk analysis.|
Of course, a company has to be willing to allocate the resources necessary for the management of security concepts. Their creation, realization, proper and consistent implementation as well as their effectiveness have to be checked by the CSO and his team.
The CSO checks the security concepts for formal shortcomings as well as weaknesses. The things he and his team point out are to be followed up upon.
To do a security concept justice, the CSO can get advice from internal expert and review the security concept in a discussion. In regularly occurring meetings, there can be targeted review-sessions with the various groups of interest planned and executed. This means, next to the people responsible for security, all stakeholders in the discussion and permission are involved. For example, depending on the direction of the concept, auditing, legal & compliance, HR, business owners etc. could be invited to the review.
Where are the possible difficulties?
Security concepts are a form of magnifying glass. They allow us to see things clearly. Even things that we wouldn’t have seen without them or things that we wouldn’t even know existed without the concepts. These insights require the willingness to deal with the discoveries. One should be wary of investing energy into security concepts that are only created because there’s some sort of formal necessity to do so, be it in form of a policy or because a CSO says so or because it’s always been done this way. This would amount to some sort of alibi-exercise that would be of little use to anyone. A systematic approach with standardized processes for creation, judgment and management of security concepts on the other hand is an excellent tool to remain up to date even in a highly dynamic context.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here