Hissen IT ►

Home News History Security Guideline

The following guideline is for customers & partners of HissenIT. It offers an overview of our recommendations in the areas IT security as well as data protection and is the foundation of our work.

IT Security for Managers - Integrate Security in Projects properly

Despite many accepted IT security standards, many IT projects and products with IT components fail at IT security. What needs to be considered, what mistakes and pitfalls to avoid.

Table of Contents

  1. IT Security in Projects and Products
  2. Enforce IT Security in Projects
  3. IT Security in Projects: From the very beginning!
  4. Security is a Process
  5. Universal IT Security Standards
  6. Do the same for Data Privacy Laws!
  7. Checklist for General / Project Managers
  8. The Human Factor
  9. Summary

IT Security in Projects and Products

By definition IT projects include the construction of a system of information technology. This may be the pure installation of existing solutions or the complete new development of custom components. A combination is also possible, such as when standard or open source software is enhanced by custom developed extensions. Whether at the end a product is created or an IT system which is otherwise used commercially, IT security plays a central role for the project's success. This also applies to systems in which IT plays only a secondary role for the whole product, such as the operator interface of a central heating device. Also, projects like building and hosting a standard web store are concerned with the subject of IT security to the same extent.

IT security is a matter for companies of all sizes. In most cases, big corporations have already implemented certain security standards, which enable IT projects to meet highest security requirements in a standardized way. By experience, smaller and medium-sized companies do not have that luxury. Mostly because tight budgets leave little room for security issues or the corresponding know-how is missing and cannot be procured easily.

Enforce IT Security in Projects

Most IT projects have a tight budget. Only in rare cases, a project manager has access to unlimited financial resources. This applies to projects of both large and small businesses alike but usually the smaller the company the bigger the problem.

If security cannot be used as a (unique) selling point for a product or for the development of a system, the project manager often has a hard job to acquire a proper and adequate budget for security issues. That is because:

A provocative question could be: Why spend money on something that deteriorates the final product? To make matters worse, in most cases, the people involved in the project have little technical understanding for the topic of security or dangerous superficial knowledge. This is understandable. IT security is one of the most complicated topics at all. An expert in this field requires not only appropriate education and training but also years of practical experience in order to implement adequate security issues in a meaningful way.

The added value of IT security cannot be regarded in the short term. A microsite for a week-long campaign might remain completely unnoticed by hackers. Nevertheless, it would be negligent to exclude IT security explicitly in such a project. On the other hand, what happens if projects lack to address security? A successfully launched web service, for instance, is inevitably going to attract hackers after some time of success. It can lose reputation very quickly when vulnerabilities are disclosed. If security has been undervalued in the project, it can be very difficult to then fix leaks in a sustainable way. As a result, the service could not only be in negative headlines for a while but a complete new development might become necessary. This might be the case because implementing a security concept in the existing system might not be possible at all.

Regarded medium and long term, products which take the security of their users and their data seriously will become successful and sustainable. Leaks are unavoidable – how to deal with these is crucial. Furthermore, minimum requirements for systems and products can be derived from various laws. If the corporate management fails to enforce these, it might slide in a case of legal negligence and legal liability for successful attacks by third parties. This should be reason enough for each project to deal with the issue of IT security seriously. The respective company management needs provide and ensure the corresponding foundation – in its own interest.

IT Security in Projects: From the very beginning!

The critical factor for the issue of security in IT projects is the moment in time. Too often, projects are considered from a business or functional point of view and are realized as a proof-of-concept, without even considering security issues. Prospects and financial forecasts are created. Then, when it comes to the implementation phase, security requirements and privacy requirements emerge – in whatever way. These can destroy the whole business idea, in the worst case. Usually, at least adjustments are needed that will affect the project plan and may be causing a disruptive factor in the project and its team. Depending on how far the proof-of-concept was planned to serve as the technical basis for the actual implementation, a complete redesign may be necessary due to the security and privacy requirements.

If you want to move these requirements to the next release after the go-live, the problems increase tremendously. Of course, this also lets the budget explode accordingly. A retiring project manager can thus also leave his successor a corresponding burden. As practice shows, any compromise in the realization will be unusable and ultimately expensive in the long run.

If there are already signed contracts with suppliers and other partners – for example, for custom developing or hosting services – before security requirements were considered, serious problems are caused for the overall project. All suppliers must be bound to the corresponding security requirements, standard contracts must be verified. Should it not be possible to adjust contracts, for example because contracts are being made with a larger company and/or a certain other dependency exists, then there has to be an own explicit risk management in place. Many web agencies, for instance, make tight price calculations to be competitive. Such agencies usually have to make separate calculations for special requirements of security catalogs. According plannings have to be adopted by the project early on.

A practical example: In an IT project, a web store should be built using standard software. It includes installation and hosting. Further changes to the web store software are not part of the project. The hosting should also include a patch management in addition to hardening the system. This must be provided for the entire life-cycle of the web shop and critical security updates of the shop software have to be applied in a timely manner. If this is not contractually agreed, additional costs will arise. Alternatively, the application owner – the owning company – must run an own process for this and must have correspondingly skilled personnel in charge.

From practical experience, it can be observe that even in companies with an established security organization, this organization is very often used much too late. Meetings of potential project teams, for example, should be accompanied by a security advisor – and by the way a data protection advisor. Thus, corresponding security and data privacy requirements can be recognized early on and no-gos can be avoided. Moreover, security advisors are usually able to discuss easier technical alternatives because of their project experience. The attendance by a security consultant may be advisable even for meetings without technical character or pure idea development.

When projects fail on IT security, then usually because of long-existing requirements which are unknown to the project team or not respected.

Security is a Process

IT security causes running costs. IT security needs permanent staff. The latter needs not necessarily to be full-time. Why is that so? – Security is a process! This applies to all types of IT projects. Here are some practical examples.

Example A

A custom developed web application is put into operation. During operation, security vulnerabilities are reported. There must exist a process to evaluate, check and fix these issues. If the software is custom-developed (in-house), this process needs to be established within the company itself. If software has been delivered by an external supplier, a corresponding contractual agreement must be installed accordingly. The interface between the internal and external processes must be defined, as well as corresponding service level agreements, such as the maximum processing time and the general cost absorption.

Example B

A standard application is hosted on the Internet. All systems have been hardened initially. Through the appearance of newly discovered vulnerabilities in standard software, a patch management process must be established. This includes among others the sighting of patches and the patch deployment. Critical security patches need to be spotted and installed promptly. Depending on the complexity of the application, a separate test system besides the actual production system is necessary to guarantee the proper functioning of the system after applying patches. Also, a regular penetration testing should be mandatory to ensure that no system component is omitted.

Example C

A system not only allows system administrators but also certain applicative roles access to customer data. Therefor, a proper logging of data access has been implemented. Even if an automatism is established which includes a fraud detection, a detection must be reported to a corresponding person to be examined and dealt with. For this, a proper process has to be created and documented. Additionally, regular audits have to be performed – also from the data privacy perspective.

Example D

For the hosting of certain systems, intrusion detection systems have been established. These allow the monitoring of unusual events in system behavior and potential attacks. From certain automatisms apart, it is necessary that suitable staff members monitor alerts and optionally initiate countermeasures.

In addition to these practical examples, for IT security the same is true as for all other things: One learns new things with every new project and, hence, own process will be adjusted accordingly.

Universal IT Security Standards

If you want to set up an IT security process for a project or a whole company, you do not have to start from scratch and you should not. There are many accepted security standards which one can build on. This applies to smaller projects and smaller companies as well. Most large companies usually have a certified IT security process in place and hence project managers receive concrete technical and non-technical requirements for IT security as well as requirements coming from data protection laws. The project manager has to check whether industry-specific standards exist which have to be applied also.

If you do not want to make the "big step" of implementing a standard security process and developing an own security organization, a so-called "Information Security Management System" (ISMS), which is understandable especially for smaller companies – security standards still help: Either for your own software development or dealing with suppliers and partners.

An advantage of the relevant security standards is that they can be used in contracts for reference. This guarantees at least some minimum level of security. If the companies participating in the project are certified according to established security standards, the application of these standards should be integrated into the corresponding contract.

A brief overview of some selected security standards without any claim to completeness:

Do the same for Data Privacy Laws!

This white paper primarily relates to IT security. However, most problems illustrated equally apply to privacy and data protection requirements. Requirements derived from laws and data regulations also need to be carried out within IT projects as early as possible. They need to be supported and implemented. Because of non-negotiable legal regulations, missing contractual agreements can become self-inflicted "project killers". Like for IT security, an appropriate specialist is also required for data protection – ideally with experience on the technical side. For the technical implementation of these requirements, again, an IT security specialist can be consulted.

Checklist for General / Project Managers

The following checklist is intended to serve IT project managers as a guide to implement the often overlooked topics of IT security within IT projects. The list is not exhaustive. IT projects differ greatly in their requirements. Should enterprise-wide requirements exist then these are, of course, to be considered in the first place. For international projects, country-specific requirements, in particular coming from data protection laws, have to be considered as well.

Levels of IT Security

Security requirements are defined in various technical levels of a project. Because IT projects differ strongly, the following list is intended only as an aid to pick up according security issues in a project early on. The requirements can be only partially meaningful or not at all for a certain project. A complete security concept, however, should at least consider all of these levels.

Technical levels:

Similar to the OSI model, the various technical levels have to be investigated if applicable for a project.

Other topics that must be covered within the project for each technical level:

In-House Development (Secure Programming)

Project Idea and Project Development

Project Kick-Off

Creating the Security Concept

External Suppliers and Service Providers

Technical Acceptance Tests

Ongoing Security Processes

The following list is intended to serve as a broad overview of the permanent security processes in the operational area of IT systems:

Operational Reliability

The Human Factor

The user as a person who makes decisions on a daily basis is part of every security process! Technical solutions always can only support the user but - security awareness - training is a MUST to ensure overall security of systems and whole organizations.

Summary

IT security is a complex undertaking. Even experienced project managers cannot fulfill this topic alone and require professional support. In small businesses, the budget shortage can require to handle the issue of security without external help. Here, security standards can help to control suppliers and partners accordingly. Therefor, the aforementioned key issues have to be considered. However, in general, it is crucial to define adequate project-specific requirements.

IT projects of all sizes must respect the principle of integrating IT security and data protection requirements in the very early stages of the project. Omissions in this area can lead to project shipwrecks or at least lead to high follow-up costs.