User Tools
policies:security:develandmaint
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| policies:security:develandmaint [2018/01/05 14:32] – [38. Security incidents responsible] deul | policies:security:develandmaint [2018/01/10 13:32] (current) – [39. Calamity procedures] deul | ||
|---|---|---|---|
| Line 2: | Line 2: | ||
| =====Development and Maintenance===== | =====Development and Maintenance===== | ||
| ====31. System ownership==== | ====31. System ownership==== | ||
| + | System ownership for scientific systems is driven by the funding mechanism. Many systems are acquired though NWO and EU funding. The PI of the project is by definition the owner of the system. Both functional and technical management are in the hands of the IT Department. | ||
| + | |||
| + | For Servers and Desktops the ownership/ | ||
| + | |||
| + | For non-scientific information systems, by definition the Scientific Director ([[policies: | ||
| ====32. New information systems procedure==== | ====32. New information systems procedure==== | ||
| + | New scientific informations systems will all fall in the 'basic risk' category. For information systems that store personel information extra security measures will be taken to adhere to the GDPR requirements. | ||
| + | ====33. Additional risk analysis==== | ||
| + | There are no scientific systems with elevated risks. So no additional risk analysis measures have to be taken. | ||
| - | ====33. Additional risc analysis==== | + | For information systems storing personel information additional |
| ====34. Operational acceptance asset==== | ====34. Operational acceptance asset==== | ||
| + | Information systems are implemented in close collaboration with the system owner, but no formal, written acceptance is in place. For systems ' | ||
| ====35. Security update procedure==== | ====35. Security update procedure==== | ||
| + | For all systems, server, desktops, stoarge and other devices security updates are implemented as a continuous process. Every day the software repositories are automatically interrogated for new security updates, which are then applied immediately. | ||
| ====36. Logfiles==== | ====36. Logfiles==== | ||
| Log files are stored local to the system where they are created. However, each log is analysed automatically and in case of a non-regular situation system managers are emailed with an indication of the non-regular behaviour. Upon receipt of such an incident the log on the system in question will be analysed. In case of a true irregularity an incident is initiated. | Log files are stored local to the system where they are created. However, each log is analysed automatically and in case of a non-regular situation system managers are emailed with an indication of the non-regular behaviour. Upon receipt of such an incident the log on the system in question will be analysed. In case of a true irregularity an incident is initiated. | ||
| Line 21: | Line 28: | ||
| The Security manager as defined by the [[policies: | The Security manager as defined by the [[policies: | ||
| ====39. Calamity procedures===== | ====39. Calamity procedures===== | ||
| + | There is no true calamity procedure, | ||
| + | * Minimize downtime of critical services | ||
| + | * Communicate the calamity to all users/ | ||
| + | * Maximize the collaborative effort within the IT Department team | ||
| + | * Strive to full resolution of the calamity | ||
policies/security/develandmaint.1515162773.txt.gz · Last modified: by deul
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
