https://wiki.egi.eu/w/api.php?action=feedcontributions&user=Kouril&feedformat=atomEGIWiki - User contributions [en]2024-03-29T05:45:23ZUser contributionsMediaWiki 1.37.1https://wiki.egi.eu/w/index.php?title=Forensic&diff=112746Forensic2021-03-04T15:26:22Z<p>Kouril: </p>
<hr />
<div>[[Category:EGI-CSIRT]]<br />
<!--{{Egi-csirt-header}}--><br />
{{New-Egi-csirt-header}} <br />
<br />
This document describes a best-effort approach for preserving and analyzing compromised Linux installations.<br />
In many situations, errors in forensics can lead to destruction of evidences, so please take precaution and contact experts if you are unsure.<br />
This document proposes commands to run to obtain or analyse some data, but the responsibility of running them is yours: if you do not know them, read the man-page and/or contact experts.<br />
<br />
You will find useful references or explanation on this wiki: http://forensicswiki.org<br />
<br />
= Preparation before incidents =<br />
<br />
The difficulty of any forensic varies on the effort attackers took to hide themselves.<br />
However, preparing yourself and your servers can ease forensics by a large amount<br />
<br />
== Prepare yourself ==<br />
<br />
=== Check your procedures ===<br />
<br />
Some questions should be answered before an incident happens, to make sure they don't hinder you while working on forensics:<br />
<br />
* Who are you supposed to contact during incidents?<br />
** Local security contacts?<br />
** External CSIRT you depend on?<br />
* What is your policy with regard to law enforcement? Will you pursue legal action?<br />
* Do you legally have to report security breaches to your users?<br />
* Who can decide to take systems and services down?<br />
* Who will coordinate actions? (like: Who will answer any press contact?)<br />
<br />
As a EGI resource centre the [https://wiki.egi.eu/wiki/SEC01 EGI CSIRT Security Incident Handling Procedure] should be used to complement your local Incident Response Procedure.<br />
<br />
=== Prepare some hardware ===<br />
<br />
During forensics, you will most likely need:<br />
* A USB key containing:<br />
** A Linux distribution of your choice, with auto-mount disabled<br />
** A static copy of forensics tools. We recommend in particular:<br />
*** [http://www.cgsecurity.org/wiki/TestDisk Testdisk] (For data recovery and carving)<br />
*** [https://www.sleuthkit.org/ The Sleuth Kit] (For offline file-system analysis and timeline)<br />
*** [http://extundelete.sourceforge.net/ extundelete] (For data recovery on ext3/ext4)<br />
* Few large capacity USB hard drive to collect disk images and evidences<br />
* [Optional] A SATA->USB converter to image disks offline (potentially with a write-blocking functionality) or a disk mirroring device.<br />
<br />
== Prepare your systems ==<br />
<br />
* Collect all system and audit logs on a remote system with strict access control.<br />
* Try to improve your file-system evidences:<br />
** Disable 'prelink' (It alters binary metadata)<br />
** Avoid cronjobs that read all files (Removes any meaning in the 'last access' metadata on file)<br />
** Avoid mounting your system with 'noatime', use 'relatime' only if necessary<br />
* Make sure to have basic tools installed on your systems that will help you collecting forensics data (you can't install them once you think you have an incident):<br />
** netstat<br />
** lsof: list of open files<br />
** pstree (from psmisc): tree of processes<br />
** gcore (from gdb): generate core images of processes<br />
<br />
= Remarks on live analysis =<br />
<br />
== Data collection order ==<br />
<br />
Data should be collected in a specific order, to avoid missing or destroying evidences.<br />
<br />
=== Observation changes the observed object ===<br />
<br />
On a live system:<br />
* Every command you run will alter (at least) file system metadata (atime on that binary)<br />
* Every data you write on disk can override data from files which were deleted before<br />
<br />
=== Forensic data is volatile ===<br />
<br />
On a live system, most of the data is volatile and usually survive only for a short time:<br />
* Processor states, caches and RAM: Nano-seconds<br />
* Network states: Milli-seconds<br />
* Running processes: Seconds<br />
* Disks: minutes<br />
(List borrowed from “Forensic Discovery”, Farmer & Venema, Addison-Wesley 2005)<br />
<br />
Please note that except for the last one, all these data are lost when the system is rebooted!<br />
<br />
== Danger from live system ==<br />
<br />
=== Compromised tools ===<br />
<br />
When performing live analysis, one has to remember that the system might have been modified to lie to you:<br />
* The kernel might have been modified<br />
* Binaries might have modified<br />
* Libraries might have been modified or are injected<br />
<br />
As a result, always doubt what you see and check if it makes sense:<br />
* Compare output of different tools (e.g. ps VS pstree VS ls /proc/pid)<br />
* Compare with external behaviour (e.g. network activity)<br />
* Compare with one own's knowledge (e.g. missing files/activity)<br />
<br />
=== Are you alone? ===<br />
<br />
If the system has been compromised, malicious actors might still be present.<br />
If you are unlucky, they might still be around, detect your actions and start deleting evidences!<br />
<br />
As a result, as soon as the breach is confirmed and baisc network/process forensics evidences have been collected, the system should be isolated from other systems.<br />
<br />
= Live (Quick & Dirty) forensics =<br />
<br />
When you are not sure you have a case and/or for physical systems (forensics on virtual machines should concentrate on snapshots (including memory snapshots)), here is a guide to collect initial data from the live system.<br />
<br />
'''All these actions MUST be performed before switching off the system''', as some of the evidences would be destroyed otherwise!<br />
<br />
== Before you start ==<br />
<br />
* Log every action you take, in order, with a time-stamp.<br />
** Use paper and pen.<br />
** Consider using ''script'' (check "man script") to log all your commands executed.<br />
** If the case is complex, large and/or sensitive (e.g. suspicious of illegal data), consider imposing a 4 eyes policy<br />
* If you connect to the system remotely, e.g. ssh, avoid using credentials that can be reused on other systems and consider them lost: change them as soon a possible<br />
* Don't store data on the harddrive:<br />
** Set HISTFILE to /dev/null <br />
** Store temporary files in a filesystem backed by a tmpfs (in RAM), remotely or on a USB drive. For example:<pre>mount | grep tmpfs # pick one in this list, we consider /dev/shm here&#10;df -h /dev/shm # verify that it is big enough&#10;mkdir /dev/shm/work && cd /dev/shm/work</pre><br />
<br />
== Collect live data ==<br />
<br />
In your temporary location, start by collecting live data from the system:<br />
<br />
* Network states:<br />
** Network sockets: <pre>netstat -apn | tee netstat_apn.txt</pre><br />
** Network environment:<pre>ip -4 neigh show | tee ip6_neigh_show.txt&#10;ip -4 route show | tee ip6_route_list.txt&#10;ip -4 link show | tee ip6_link_show.txt&#10;ip -6 neigh show | tee ip6_neigh_show.txt&#10;ip -6 route show | tee ip6_route_list.txt&#10;ip -6 link show | tee ip6_link_show.txt</pre><br />
* Users' logins:<pre>w > w.txt&#10;last | tee last.txt&#10;lastlog | tee lastlog.txt</pre><br />
* Running processes:<pre>ps -auxwwwe | tee ps_auxwwwe.txt&#10;pstree -lap | tee pstree_lap.txt</pre><br />
* Open sockets/files:<pre>lsof -b -l -P -X -n -o -R -U | tee lsof_blPXnoRU.txt&#10;lsof -b -l -P -X -n -o -R | tee lsof_blPXnoR.txt</pre><br />
* List of mounted devices: <pre>cat /proc/mounts | tee proc_mounts.txt</pre><br />
* Loaded kernel modules: <pre>cat /proc/modules | tee proc_modules&#10;ls /sys/modules |tee sys_modules</pre><br />
<br />
== Collect malicious process data ==<br />
<br />
Review rapidly the data you have collected and look for oddities, for example:<br />
* Processes listening on a raw socket (not related to dhcp)<br />
* Processes listening on ports that you don't know about, can't find on the internet<br />
* Processes spawned by a process that should not do it usually<br />
* Processes with network activity that should not do it usually<br />
<br />
For each of such process:<br />
* Keep the PID number in a separate variable and folder: <pre>export PID=12345 # <- INSERT PROCESS-ID (PID) HERE&#10;mkdir $PID&#10;cd $PID</pre><br />
* Stop the process (can't be caught): <pre>kill -STOP ${PID}</pre><br />
* Copy the executable: <pre>cp /proc/${PID}/exe ${PID}.exe</pre><br />
* Dump a core of the process: <pre>gcore ${PID}</pre><br />
** If you don't have gcore, you need to do it manuall: <pre>gdb -p ${PID}&#10; # Type "gcore"&#10; # Type "detach"&#10; # Type "exit"</pre><br />
* Copy all interesting open files:<br />
** List files opened by the process: <pre>lsof -np ${PID}</pre><br />
** Copy 'deleted' files: <pre>cp /proc/${PID}/fd/${FDNUM} ${FILENAME} # FDNUM and FILENAME should be taken from the output of lsof</pre><br />
** Copy files stored in /dev/shm: <pre>cp /dev/shm/${FILENAME} ${FILENAME} # FILENAME should be taken from the output of lsof</pre><br />
* Copy all files from the proc folder: <pre>tar cvf proc_${PID}.tar /proc/${PID}/{auxv,cgroup,cmdline,comm,environ,limits,maps,sched,schedstat,sessionid,smaps, stack,stat,statm,status,syscall,wchan}</pre><br />
* Get out of your temporary folder <pre>cd ..</pre><br />
<br />
== Collect filesystem metadata ==<br />
<br />
For each locally mounted filesystem, you should collect their file metadata (access, modification and change times).<br />
The list of local filesystem can usually be found with: <pre>grep '^/dev/' /proc/mounts</pre><br />
<br />
For each of them:<br />
* Create a mount point: <pre>mkdir mountpoint</pre><br />
* Bind mount the existing mounted point there, e.g. for '/': <pre>mount --bind / mountpoint</pre><br />
* Remount it read-only (this cannot be done in a single step!): <pre>mount -o remount,ro mountpoint</pre><br />
* Get into the mount point: <pre>cd mountpoint</pre><br />
* Get all metadata: <pre>find . -print0 | xargs -0 stat -c "%Y %X %Z %A %U %G %s %n" -- | tee ../root.files # replace 'root' with the actual filesystem you mounted</pre><br />
* Get out of the mountpoint and unmount it: <pre>cd .. &#10;umount mountpoint</pre><br />
<br />
Once you have collected all this metadata and extracted it to another location, the timeline of each filesystem can be rebuilt using this script:<br />
<pre class="toccolours mw-collapsible mw-collapsed" id="TimelineDecorator">#! /usr/bin/python<br />
<br />
from __future__ import print_function<br />
<br />
from datetime import datetime<br />
import sys<br />
try:<br />
import pytz<br />
except:<br />
pass<br />
<br />
if len(sys.argv) > 1:<br />
try:<br />
timezone = pytz.timezone(sys.argv[1])<br />
except:<br />
print("Impossible to use this timezone")<br />
sys.exit(-1)<br />
else:<br />
timezone = None<br />
<br />
def print_line(flags, t, mode, user, group, size, name):<br />
when = datetime.utcfromtimestamp(float(t))<br />
if timezone is not None:<br />
try:<br />
when = pytz.utc.localize(when).astimezone(timezone)<br />
except:<br />
print("Timezone issue!")<br />
sys.exit(-1)<br />
print(' '.join([t, when.isoformat(), flags, mode, user, group, size, name]))<br />
<br />
for line in sys.stdin:<br />
line = line[:-1]<br />
(m, a, c, mode, user, group, size, name) = line.split(" ", 7)<br />
if m == a:<br />
if m == c:<br />
print_line("mac", m, mode, user, group, size, name)<br />
else:<br />
print_line("ma-", m, mode, user, group, size, name)<br />
print_line("--c", c, mode, user, group, size, name)<br />
else:<br />
if m == c:<br />
print_line("m-c", m, mode, user, group, size, name)<br />
print_line("-a-", a, mode, user, group, size, name)<br />
else:<br />
print_line("m--", m, mode, user, group, size, name)<br />
print_line("-a-", a, mode, user, group, size, name)<br />
print_line("--c", c, mode, user, group, size, name)<br />
</pre><br />
<br />
== [Optional] Automated tests ==<br />
<br />
You can run some automated tools to try to identify malicious activity/files, but you first need:<br />
* To have these tools installed (e.g. [http://www.chkrootkit.org chkrootkit], [http://rkhunter.sourceforge.net rkhunter], [http://www.ossec.net/main/rootcheck ossec-rootcheck])<br />
* To first remount all your local filesystems as read only. A first approach for this remount can use the following code, but you should rather review the list and remount them manually. <pre>for mountpoint in $(grep '^/dev/' /proc/mounts |cut -d ' ' -f 2 |sort -r); do &#10; echo mount -o remount,ro $mountpoint&#10;done</pre><br />
<br />
You can also (after remounting all filesystems read only) use your package management system to verify installed packages (save the output). On RedHat based systems, this is '''rpm -Va''', on Debian based system, '''debsums'''.<br />
<br />
== Stopping the system ==<br />
<br />
Before stopping the system, remember to take out all the data you have already collected using e.g. scp or rsync if you extracted it in a tmpfs.<br />
You might also want to run 'sync' to make sure that all data is written on disk.<br />
<br />
There are two ways of stopping a system:<br />
* Run the normal shutdown procedure: this will close all running program properly, which would preserve e.g. databases, but would write a lot on the disk, potentially destroying evidences<br />
* Simply unplug the power cables of the system: this will kill all running programs, potentially damaging e.g. databases, but would preserve more evidences.<br />
<br />
We usually recommend the later.<br />
<br />
= Offline analysis =<br />
<br />
Most of the analysis usually happens offline. Here we have less time pressure.<br />
<br />
== Copying disks ==<br />
<br />
One of the most important rules of forensics is to never worker on the original supports, thus you need to copy the data (some will even recommend to only work on copies of copies in order to avoid copying the original again if you have a corruption).<br />
<br />
There are mainly 3 ways of copying a disk :<br />
* Use a disk imaging/mirroring device<br />
* Use an external hard drive docking bay<br />
* Use an internal hot-swappable connector<br />
<br />
For the last two possibility, one has to be very cautious not to modify any data:<br />
* The operating system on which the disk is plugged must have any auto-mount feature disabled<br />
* If more than one device is connected, they should be plugged in sequentially, to make sure that their identifiers are properly mapped<br />
* Any command typed can irremediably destroy data and should be checked multiple time<br />
<br />
Once drives are identified, we recommend using dd to image the disk: <pre>dd if=/dev/sdX of=mybigfile.img bs=65536 conv=noerror,sync # inverting if and of will destroy all evidences!</pre><br />
<br />
== Collect filesystem metadata ==<br />
<br />
While filesystem metadata can be collected from live systems, collecting it from cold disk have some advantages:<br />
* While live system analysis can be affected by rootkit, this one cannot<br />
* On ext4 filesystem, normal live tools do not extract the '''creation''' time. Forensic tools do<br />
<br />
We recommend using fls and mactime from the [https://www.sleuthkit.org/ Sleuth Kit] for collecting such metadata, see the corresponding wiki page: http://wiki.sleuthkit.org/index.php?title=Timeline<br />
<br />
== Carving unallocated blocks ==<br />
<br />
Data on file-systems is not deleted when a file is deleted, but is kept on unallocated data blocks. These blocks might be overridden by the content of new files.<br />
Until then, that data can be recovered from the harddrive:<br />
* For a given pattern (e.g. sshd logs), it’s possible (and usually fruitful) to simply grep the raw disk<br />
* Dedicated tools, like PhotoRec from the [http://www.cgsecurity.org/wiki/TestDisk_Download testdisk] utility, can try to rebuild files based on built-in patterns<br />
<br />
= Exploiting forensic data =<br />
<br />
There is one basic thing to remember when doing forensics: always try to assert how much you can trust what you see.<br />
Most of it is just bits on some disks, which could have been altered by an attacker, thus:<br />
* Never fully trust data from a compromised system, ask yourself if it could have been tempered with and what would that mean<br />
* Try to corroborate different sources, either between different local sources or with external sources<br />
* Check if what you are seeing is possible on a normal system, as part of the normal workflow<br />
<br />
== Reading file system timelines ==<br />
<br />
When looking a a file system timeline, one should first remember that:<br />
* atime and mtime can easily be faked and are manipulated by the system itself (e.g. when extracting files from archives, downloading files, etc). You should start by ignoring them and only look at them when you understand the basic of the activity on the system<br />
* ctime are less likely to be manipulated<br />
* crtime and dtime are rarely manipulated<br />
<br />
We recommend looking for the following artefacts:<br />
* Weird folder names (e.g. '...'), content in temporary and world-writable folders (e.g /var/tmp, /dev/shm, /tmp)<br />
* Binary or library ctime or crtime modified while the package was not updated (no yum log/transaction, man page not updated, ...)<br />
* Traces of compilation: atime on files in /usr/include<br />
* Impossible timestamp combinaisons:<br />
** File/folder created after its last modification (crtime after ctime)<br />
** File/folder created after the last modification of its parent folder (crtime of a file/folder after ctime of its parent folder)<br />
<br />
== Malware analysis ==<br />
<br />
Malware analysis is complex and, with the ongoing competition between criminals and professional security researchers, is now mostly inaccessible without proper tool or training.<br />
If you have some doubts about a library or binary, you can take a quick look by:<br />
* Running '''string -a''' and looking for any strange strings. Unfortunately most advanced malware will obfuscate their strings, making such analysis useless. However most legit binary and library will contain help description and text, which absence could be considered suspicious<br />
* Run the malware in a controlled environment (e.g. isolated VM with no network), under strace and ltrace, to look for strange activity. If the binary is supposed to consume input (e.g. password for SSH/SSHD), feed it with some known input and check if that input has been compared with other strings<br />
<br />
= Credits =<br />
<br />
This document, compiled by Vincent Brillault in 2017, is based on:<br />
* Trainings written by Leif Nixon<br />
* A forensics HowTo written by Heiko Reese</div>Kourilhttps://wiki.egi.eu/w/index.php?title=Forensic&diff=112745Forensic2021-03-04T15:23:52Z<p>Kouril: </p>
<hr />
<div>[[Category:EGI-CSIRT]]<br />
<!--{{Egi-csirt-header}}--><br />
{{New-Egi-csirt-header}} <br />
<br />
This document describes a best-effort approach for preserving and analyzing compromised Linux installations.<br />
In many situations, errors in forensics can lead to destruction of evidences, so please take precaution and contact experts if you are unsure.<br />
This document proposes commands to run to obtain or analyse some data, but the responsibility of running them is yours: if you do not know them, read the man-page and/or contact experts.<br />
<br />
You will find useful references or explanation on this wiki: http://forensicswiki.org<br />
<br />
= Preparation before incidents =<br />
<br />
The difficulty of any forensic varies on the effort attackers took to hide themselves.<br />
However, preparing yourself and your servers can ease forensics by a large amount<br />
<br />
== Prepare yourself ==<br />
<br />
=== Check your procedures ===<br />
<br />
Some questions should be answered before an incident happens, to make sure they don't hinder you while working on forensics:<br />
<br />
* Who are you supposed to contact during incidents?<br />
** Local security contacts?<br />
** External CSIRT you depend on?<br />
* What is your policy with regard to law enforcement? Will you pursue legal action?<br />
* Do you legally have to report security breaches to your users?<br />
* Who can decide to take systems and services down?<br />
* Who will coordinate actions? (like: Who will answer any press contact?)<br />
<br />
As a EGI resource centre the [https://wiki.egi.eu/wiki/SEC01 EGI CSIRT Security Incident Handling Procedure] should be used to complement your local Incident Response Procedure.<br />
<br />
=== Prepare some hardware ===<br />
<br />
During forensics, you will most likely need:<br />
* A USB key containing:<br />
** A Linux distribution of your choice, with auto-mount disabled<br />
** A static copy of forensics tools. We recommend in particular:<br />
*** [http://www.cgsecurity.org/wiki/TestDisk Testdisk] (For data recovery and carving)<br />
*** [https://www.sleuthkit.org/ The Sleuth Kit] (For offline file-system analysis and timeline)<br />
*** [http://extundelete.sourceforge.net/ extundelete] (For data recovery on ext3/ext4)<br />
* Few large capacity USB hard drive to collect disk images and evidences<br />
* [Optional] A SATA->USB converter to image disks offline (potentially with a write-blocking functionality) or a disk mirroring device.<br />
<br />
== Prepare your systems ==<br />
<br />
* Collect all system and audit logs on a remote system with strict access control.<br />
* Try to improve your file-system evidences:<br />
** Disable 'prelink' (It alters binary metadata)<br />
** Avoid cronjobs that read all files (Removes any meaning in the 'last access' metadata on file)<br />
** Avoid mounting your system with 'noatime', use 'relatime' only if necessary<br />
* Make sure to have basic tools installed on your systems that will help you collecting forensics data (you can't install them once you think you have an incident):<br />
** netstat<br />
** lsof: list of open files<br />
** pstree (from psmisc): tree of processes<br />
** gcore (from gdb): generate core images of processes<br />
<br />
= Remarks on live analysis =<br />
<br />
== Data collection order ==<br />
<br />
Data should be collected in a specific order, to avoid missing or destroying evidences.<br />
<br />
=== Observation changes the observed object ===<br />
<br />
On a live system:<br />
* Every command you run will alter (at least) file system metadata (atime on that binary)<br />
* Every data you write on disk can override data from files which were deleted before<br />
<br />
=== Forensic data is volatile ===<br />
<br />
On a live system, most of the data is volatile and usually survive only for a short time:<br />
* Processor states, caches and RAM: Nano-seconds<br />
* Network states: Milli-seconds<br />
* Running processes: Seconds<br />
* Disks: minutes<br />
(List borrowed from “Forensic Discovery”, Farmer & Venema, Addison-Wesley 2005)<br />
<br />
Please note that except for the last one, all these data are lost when the system is rebooted!<br />
<br />
== Danger from live system ==<br />
<br />
=== Compromised tools ===<br />
<br />
When performing live analysis, one has to remember that the system might have been modified to lie to you:<br />
* The kernel might have been modified<br />
* Binaries might have modified<br />
* Libraries might have been modified or are injected<br />
<br />
As a result, always doubt what you see and check if it makes sense:<br />
* Compare output of different tools (e.g. ps VS pstree VS ls /proc/pid)<br />
* Compare with external behaviour (e.g. network activity)<br />
* Compare with one own's knowledge (e.g. missing files/activity)<br />
<br />
=== Are you alone? ===<br />
<br />
If the system has been compromised, malicious actors might still be present.<br />
If you are unlucky, they might still be around, detect your actions and start deleting evidences!<br />
<br />
As a result, as soon as the breach is confirmed and baisc network/process forensics evidences have been collected, the system should be isolated from other systems.<br />
<br />
= Live (Quick & Dirty) forensics =<br />
<br />
When you are not sure you have a case and/or for physical systems (forensics on virtual machines should concentrate on snapshots (including memory snapshots)), here is a guide to collect initial data from the live system.<br />
<br />
'''All these actions MUST be performed before switching off the system''', as some of the evidences would be destroyed otherwise!<br />
<br />
== Before you start ==<br />
<br />
* Log every action you take, in order, with a time-stamp.<br />
** Use paper and pen.<br />
** Consider using ''script'' (check "man script") to log all your commands executed.<br />
** If the case is complex, large and/or sensitive (e.g. suspicious of illegal data), consider imposing a 4 eyes policy<br />
* If you connect to the system remotely, e.g. ssh, avoid using credentials that can be reused on other systems and consider them lost: change them as soon a possible<br />
* Don't store data on the harddrive:<br />
** Set HISTFILE to /dev/null <br />
** Store temporary files in a filesystem backed by a tmpfs (in RAM), remotely or on a USB drive. For example:<pre>mount | grep tmpfs # pick one in this list, we consider /dev/shm here&#10;df -h /dev/shm # verify that it is big enough&#10;mkdir /dev/shm/work && cd /dev/shm/work</pre><br />
<br />
== Collect live data ==<br />
<br />
In your temporary location, start by collecting live data from the system:<br />
<br />
* Network states:<br />
** Network sockets: <pre>netstat -apn | tee netstat_apn.txt</pre><br />
** Network environment:<pre>ip -4 neigh show | tee ip6_neigh_show.txt&#10;ip -4 route show | tee ip6_route_list.txt&#10;ip -4 link show | tee ip6_link_show.txt&#10;ip -6 neigh show | tee ip6_neigh_show.txt&#10;ip -6 route show | tee ip6_route_list.txt&#10;ip -6 link show | tee ip6_link_show.txt</pre><br />
* Users' logins:<pre>w > w.txt&#10;last | tee last.txt&#10;lastlog | tee lastlog.txt</pre><br />
* Running processes:<pre>ps -auxwwwe | tee ps_auxwwwe.txt&#10;pstree -lap | tee pstree_lap.txt</pre><br />
* Open sockets/files:<pre>lsof -b -l -P -X -n -o -R -U | tee lsof_blPXnoRU.txt&#10;lsof -b -l -P -X -n -o -R | tee lsof_blPXnoR.txt</pre><br />
* List of mounted devices: <pre>cat /proc/mounts | tee proc_mounts.txt</pre><br />
* Loaded kernel modules: <pre>cat /proc/modules | tee proc_modules&#10;ls /sys/modules |tee sys_modules</pre><br />
<br />
== Collect malicious process data ==<br />
<br />
Review rapidly the data you have collected and look for oddities, for example:<br />
* Processes listening on a raw socket (not related to dhcp)<br />
* Processes listening on ports that you don't know about, can't find on the internet<br />
* Processes spawned by a process that should not do it usually<br />
* Processes with network activity that should not do it usually<br />
<br />
For each of such process:<br />
* Keep the PID number in a separate variable and folder: <pre>export PID=12345 # <- INSERT PROCESS-ID (PID) HERE&#10;mkdir $PID&#10;cd $PID</pre><br />
* Stop the process (can't be caught): <pre>kill -STOP ${PID}</pre><br />
* Copy the executable: <pre>cp /proc/${PID}/exe ${PID}.exe</pre><br />
* Dump a core of the process: <pre>gcore ${PID}</pre><br />
** If you don't have gcore, you need to do it manuall: <pre>gdb -p ${PID}&#10; # Type "gcore"&#10; # Type "detach"&#10; # Type "exit"</pre><br />
* Copy all interesting open files:<br />
** List files opened by the process: <pre>lsof -np ${PID}</pre><br />
** Copy 'deleted' files: <pre>cp /proc/${PID}/fd/${FDNUM} ${FILENAME} # FDNUM and FILENAME should be taken from the output of lsof</pre><br />
** Copy files stored in /dev/shm: <pre>cp /dev/shm/${FILENAME} ${FILENAME} # FILENAME should be taken from the output of lsof</pre><br />
* Copy all files from the proc folder: <pre>tar cvf proc_${PID}.tar /proc/${PID}/{auxv,cgroup,cmdline,comm,environ,limits,maps,sched,schedstat,sessionid,smaps, stack,stat,statm,status,syscall,wchan}</pre><br />
* Get out of your temporary folder <pre>cd ..</pre><br />
<br />
== Collect filesystem metadata ==<br />
<br />
For each locally mounted filesystem, you should collect their file metadata (access, modification and change times).<br />
The list of local filesystem can usually be found with: <pre>grep '^/dev/' /proc/mounts</pre><br />
<br />
For each of them:<br />
* Create a mount point: <pre>mkdir mountpoint</pre><br />
* Bind mount the existing mounted point there, e.g. for '/': <pre>mount --bind / mountpoint</pre><br />
* Remount it read-only (this cannot be done in a single step!): <pre>mount -o remount,ro mountpoint</pre><br />
* Get into the mount point: <pre>cd mountpoint</pre><br />
* Get all metadata: <pre>find . -print0 | xargs -0 stat -c "%Y %X %Z %A %U %G %s %n" -- | tee ../root.files # replace 'root' with the actual filesystem you mounted</pre><br />
* Get out of the mountpoint and unmount it: <pre>cd .. &#10;umount mountpoint</pre><br />
<br />
Once you have collected all this metadata and extracted it to another location, the timeline of each filesystem can be rebuilt using this script:<br />
<pre class="toccolours mw-collapsible mw-collapsed" id="TimelineDecorator">#! /usr/bin/python<br />
<br />
from __future__ import print_function<br />
<br />
from datetime import datetime<br />
import sys<br />
try:<br />
import pytz<br />
except:<br />
pass<br />
<br />
if len(sys.argv) > 1:<br />
try:<br />
timezone = pytz.timezone(sys.argv[1])<br />
except:<br />
print("Impossible to use this timezone")<br />
sys.exit(-1)<br />
else:<br />
timezone = None<br />
<br />
def print_line(flags, t, mode, user, group, size, name):<br />
when = datetime.utcfromtimestamp(float(t))<br />
if timezone is not None:<br />
try:<br />
when = pytz.utc.localize(when).astimezone(timezone)<br />
except:<br />
print("Timezone issue!")<br />
sys.exit(-1)<br />
print(' '.join([t, when.isoformat(), flags, mode, user, group, size, name]))<br />
<br />
for line in sys.stdin:<br />
line = line[:-1]<br />
(m, a, c, mode, user, group, size, name) = line.split(" ", 6)<br />
if m == a:<br />
if m == c:<br />
print_line("mac", m, mode, user, group, size, name)<br />
else:<br />
print_line("ma-", m, mode, user, group, size, name)<br />
print_line("--c", c, mode, user, group, size, name)<br />
else:<br />
if m == c:<br />
print_line("m-c", m, mode, user, group, size, name)<br />
print_line("-a-", a, mode, user, group, size, name)<br />
else:<br />
print_line("m--", m, mode, user, group, size, name)<br />
print_line("-a-", a, mode, user, group, size, name)<br />
print_line("--c", c, mode, user, group, size, name)<br />
</pre><br />
<br />
== [Optional] Automated tests ==<br />
<br />
You can run some automated tools to try to identify malicious activity/files, but you first need:<br />
* To have these tools installed (e.g. [http://www.chkrootkit.org chkrootkit], [http://rkhunter.sourceforge.net rkhunter], [http://www.ossec.net/main/rootcheck ossec-rootcheck])<br />
* To first remount all your local filesystems as read only. A first approach for this remount can use the following code, but you should rather review the list and remount them manually. <pre>for mountpoint in $(grep '^/dev/' /proc/mounts |cut -d ' ' -f 2 |sort -r); do &#10; echo mount -o remount,ro $mountpoint&#10;done</pre><br />
<br />
You can also (after remounting all filesystems read only) use your package management system to verify installed packages (save the output). On RedHat based systems, this is '''rpm -Va''', on Debian based system, '''debsums'''.<br />
<br />
== Stopping the system ==<br />
<br />
Before stopping the system, remember to take out all the data you have already collected using e.g. scp or rsync if you extracted it in a tmpfs.<br />
You might also want to run 'sync' to make sure that all data is written on disk.<br />
<br />
There are two ways of stopping a system:<br />
* Run the normal shutdown procedure: this will close all running program properly, which would preserve e.g. databases, but would write a lot on the disk, potentially destroying evidences<br />
* Simply unplug the power cables of the system: this will kill all running programs, potentially damaging e.g. databases, but would preserve more evidences.<br />
<br />
We usually recommend the later.<br />
<br />
= Offline analysis =<br />
<br />
Most of the analysis usually happens offline. Here we have less time pressure.<br />
<br />
== Copying disks ==<br />
<br />
One of the most important rules of forensics is to never worker on the original supports, thus you need to copy the data (some will even recommend to only work on copies of copies in order to avoid copying the original again if you have a corruption).<br />
<br />
There are mainly 3 ways of copying a disk :<br />
* Use a disk imaging/mirroring device<br />
* Use an external hard drive docking bay<br />
* Use an internal hot-swappable connector<br />
<br />
For the last two possibility, one has to be very cautious not to modify any data:<br />
* The operating system on which the disk is plugged must have any auto-mount feature disabled<br />
* If more than one device is connected, they should be plugged in sequentially, to make sure that their identifiers are properly mapped<br />
* Any command typed can irremediably destroy data and should be checked multiple time<br />
<br />
Once drives are identified, we recommend using dd to image the disk: <pre>dd if=/dev/sdX of=mybigfile.img bs=65536 conv=noerror,sync # inverting if and of will destroy all evidences!</pre><br />
<br />
== Collect filesystem metadata ==<br />
<br />
While filesystem metadata can be collected from live systems, collecting it from cold disk have some advantages:<br />
* While live system analysis can be affected by rootkit, this one cannot<br />
* On ext4 filesystem, normal live tools do not extract the '''creation''' time. Forensic tools do<br />
<br />
We recommend using fls and mactime from the [https://www.sleuthkit.org/ Sleuth Kit] for collecting such metadata, see the corresponding wiki page: http://wiki.sleuthkit.org/index.php?title=Timeline<br />
<br />
== Carving unallocated blocks ==<br />
<br />
Data on file-systems is not deleted when a file is deleted, but is kept on unallocated data blocks. These blocks might be overridden by the content of new files.<br />
Until then, that data can be recovered from the harddrive:<br />
* For a given pattern (e.g. sshd logs), it’s possible (and usually fruitful) to simply grep the raw disk<br />
* Dedicated tools, like PhotoRec from the [http://www.cgsecurity.org/wiki/TestDisk_Download testdisk] utility, can try to rebuild files based on built-in patterns<br />
<br />
= Exploiting forensic data =<br />
<br />
There is one basic thing to remember when doing forensics: always try to assert how much you can trust what you see.<br />
Most of it is just bits on some disks, which could have been altered by an attacker, thus:<br />
* Never fully trust data from a compromised system, ask yourself if it could have been tempered with and what would that mean<br />
* Try to corroborate different sources, either between different local sources or with external sources<br />
* Check if what you are seeing is possible on a normal system, as part of the normal workflow<br />
<br />
== Reading file system timelines ==<br />
<br />
When looking a a file system timeline, one should first remember that:<br />
* atime and mtime can easily be faked and are manipulated by the system itself (e.g. when extracting files from archives, downloading files, etc). You should start by ignoring them and only look at them when you understand the basic of the activity on the system<br />
* ctime are less likely to be manipulated<br />
* crtime and dtime are rarely manipulated<br />
<br />
We recommend looking for the following artefacts:<br />
* Weird folder names (e.g. '...'), content in temporary and world-writable folders (e.g /var/tmp, /dev/shm, /tmp)<br />
* Binary or library ctime or crtime modified while the package was not updated (no yum log/transaction, man page not updated, ...)<br />
* Traces of compilation: atime on files in /usr/include<br />
* Impossible timestamp combinaisons:<br />
** File/folder created after its last modification (crtime after ctime)<br />
** File/folder created after the last modification of its parent folder (crtime of a file/folder after ctime of its parent folder)<br />
<br />
== Malware analysis ==<br />
<br />
Malware analysis is complex and, with the ongoing competition between criminals and professional security researchers, is now mostly inaccessible without proper tool or training.<br />
If you have some doubts about a library or binary, you can take a quick look by:<br />
* Running '''string -a''' and looking for any strange strings. Unfortunately most advanced malware will obfuscate their strings, making such analysis useless. However most legit binary and library will contain help description and text, which absence could be considered suspicious<br />
* Run the malware in a controlled environment (e.g. isolated VM with no network), under strace and ltrace, to look for strange activity. If the binary is supposed to consume input (e.g. password for SSH/SSHD), feed it with some known input and check if that input has been compared with other strings<br />
<br />
= Credits =<br />
<br />
This document, compiled by Vincent Brillault in 2017, is based on:<br />
* Trainings written by Leif Nixon<br />
* A forensics HowTo written by Heiko Reese</div>Kourilhttps://wiki.egi.eu/w/index.php?title=SVG:Meltdown_and_Spectre_Vulnerabilities&diff=98479SVG:Meltdown and Spectre Vulnerabilities2018-02-02T13:12:25Z<p>Kouril: </p>
<hr />
<div>{{svg-header}} <br />
<br />
== Purpose of this page ==<br />
<br />
To provide more detailed information about the Meltdown and Spectre vulnerabilities, to complement the advisory, [[SVG:Advisory-SVG-CVE-2017-5753]].<br />
<br />
We are continuing to add new information when we become aware of it, and the situation continues to change (02nd February 2018). <br />
<br />
== What are they? ==<br />
<br />
These are vulnerabilities in the design of the chip hardware, and cannot be fully resolved by patching operating systems. However patches are available which mitigate these problems.<br />
* Meltdown (CVE-2017-5754) affects most Intel chips.<br />
* Spectre (CVE-2017-5753 and CVE-2017-5715) affects a wide range of chips.<br />
<br />
For more details, see [https://meltdownattack.com/ https://meltdownattack.com/ ], [https://spectreattack.com/ https://spectreattack.com/] and [https://googleprojectzero.blogspot.dk/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.dk/2018/01/reading-privileged-memory-with-side.html] <br />
<br />
== How to mitigate these vulnerabilities ==<br />
<br />
Each CVE can be mitigated via different ways:<br />
* Meltdown (CVE-2017-5754) can be mitigated via [https://en.wikipedia.org/wiki/Kernel_page-table_isolation Kernel Page Table Isolation], which is enabled by default in latest linux kernels<br />
* Spectre Variant 1 (CVE-2017-5753) has to be mitigated in each software which can be vulnerable. The latest linux kernel contains fixes to protect itself (does not protect other software).<br />
* Spectre Variant 2 (CVE-2017-5715) can be (at least partially) mitigated via at least two different approach:<br />
** Using new Intel-specific MSR, added via a microcode update, to control indirect branch restricted speculation (IBRS): Both a kernel and a microcode update are required. In addition, in case of virtualization, an update of the virtualization software (e.g. qemu & virt) is required to expose the new MSR to the VM.<br />
** Using "retpoline", a new software construct that can mitigate, on most CPUs, the vulnerability<br />
<br />
=== RedHat ===<br />
<br />
As of Feb 2nd 2018, RedHat has [https://access.redhat.com/security/vulnerabilities/speculativeexecution offered new kernel updates that can mitigate Meltdown (CVE-2017-5754), Spectre Variant 1 (CVE-2017-5753) and Spectre Variant 2 (CVE-2017-5715)].<br />
<br />
However, due to instability issues, it has [https://access.redhat.com/errata/RHSA-2018:0093 removed the microcode updates required for Spectre Variant 2 (CVE-2017-5715)]. Until Intel releases stable microcode or RedHat switches to 'retpoline', no mitigation for Spectre Variant 2 (CVE-2017-5715) is safely usable.<br />
<br />
It is currently possible to mitigate Meltdown (CVE-2017-5754) and Spectre Variant 1 (CVE-2017-5753) by:<br />
* On RHEL7: Updating the kernel to 3.10.0-693.11.6.el7, see [https://access.redhat.com/errata/RHSA-2018:0007 RHSA-2018:0007]<br />
* On RHEL6: Updating the kernel to 2.6.32-696.18.7.el6, see [https://access.redhat.com/errata/RHSA-2018:0008 RHSA-2018:0008]<br />
<br />
=== Centos ===<br />
<br />
Centos is following RedHat (see above).<br />
<br />
It is currently possible to mitigate Meltdown (CVE-2017-5754) and Spectre Variant 1 (CVE-2017-5753) by:<br />
* On Centos 7: Updating the kernel to 3.10.0-693.11.6.el7, see [https://lists.centos.org/pipermail/centos-announce/2018-January/022696.html CESA-2018:0007]<br />
* On Centos 6: Updating the kernel to 2.6.32-696.18.7.el6, see [https://lists.centos.org/pipermail/centos-announce/2018-January/022701.html CESA-2018:0008]<br />
<br />
=== Scientific Linux ===<br />
<br />
Scientific Linux is following RedHat (see above).<br />
<br />
It is currently possible to mitigate Meltdown (CVE-2017-5754) and Spectre Variant 1 (CVE-2017-5753) by:<br />
* On SL7: Updating the kernel to 3.10.0-693.11.6.el7, see [https://www.scientificlinux.org/category/sl-errata/slsa-20180007-1/ SLSA-2018:0007-1]<br />
* On SL6: Updating the kernel to 2.6.32-696.18.7.el6, see [https://www.scientificlinux.org/category/sl-errata/slsa-20180008-1/ SLSA-2018:0008-1]<br />
<br />
Additional details as well as information on other systems and platforms can be found in the next section.<br />
<br />
== More Information ==<br />
<br />
=== Relevant Advisories ===<br />
==== CERN ====<br />
<br />
CERN has compiled information which is useful for many EGI sites:<br />
<br />
[https://security.web.cern.ch/security/advisories/spectre-meltdown/spectre-meltdown.shtml https://security.web.cern.ch/security/advisories/spectre-meltdown/spectre-meltdown.shtml]<br />
<br />
==== Intel ====<br />
<br />
Intel has initially, on January 8th, [https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File released new microcodes] to complement the IBRS kernel patchset. However, these new microcodes are in fact '''unstable''' and Intel has since then recommended to stop deploying them.<br />
<br />
Intel latest recommendation can be found in their advisory, [https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr INTEL-SA-00088]<br />
<br />
More updates and information:<br />
* [https://newsroom.intel.com/news/intel-responds-to-security-research-findings/ Jan 3rd: Initial response]<br />
* [https://newsroom.intel.com/news-releases/intel-issues-updates-protect-systems-security-exploits/ Jan 4th]<br />
* [https://newsroom.intel.com/news/intel-offers-security-issue-update/ Jan 9th: Microcode released]<br />
* [https://newsroom.intel.com/editorials/intel-security-issue-update-initial-performance-data-results-client-systems/ Jan 10th: performance impact analysis]<br />
* [https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/ Jan 11th: Microcode unstability reported]<br />
* [https://newsroom.intel.com/news/firmware-updates-and-initial-performance-data-for-data-center-systems/ Jan 17th]<br />
* [https://newsroom.intel.com/news/root-cause-of-reboot-issue-identified-updated-guidance-for-customers-and-partners/ Jan 22th: Instabilities causes found for 2 Intel series]<br />
<br />
=== Linux Distributions ===<br />
==== RedHat ====<br />
<br />
'''Important! [as of 17th January]'''<br />
<br />
RedHat has issued new microcode_ctl packages to rollback the latest updates, see [https://access.redhat.com/errata/RHSA-2018:0093 RHSA-2018:0093].<br />
<br />
<br> <br />
<br />
RedHat description: <br />
* [https://access.redhat.com/security/vulnerabilities/speculativeexecution https://access.redhat.com/security/vulnerabilities/speculativeexecution]<br />
* [https://access.redhat.com/articles/3307751 https://access.redhat.com/articles/3307751 (subscription required)]<br />
* [https://access.redhat.com/solutions/3315431 https://access.redhat.com/solutions/3315431 (subscription required)]<br />
<br />
RedHat CVE info:<br />
* [https://access.redhat.com/security/cve/CVE-2017-5754 CVE-2017-5754] <br />
* [https://access.redhat.com/security/cve/CVE-2017-5753 CVE-2017-5753] <br />
* [https://access.redhat.com/security/cve/CVE-2017-5715 CVE-2017-5715]<br />
<br />
==== CentOS ====<br />
<br />
'''Important! [as of 17th January]'''<br />
<br />
Centos seems to be following Redhat in the revert of the microcode_ctl package, see [https://git.centos.org/blob/rpms!microcode_ctl.git/c7/SOURCES!disclaimer the disclaimer in the sources of the last package]<br />
<br />
<br><br />
<br />
CentOS 7:<br />
<br />
* kernel Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022696.html CESA-2018:0007]<br />
* microcode_ctl Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022697.html CESA-2018:0012] <br> also needs dracut BugFix Update for AMD: [https://lists.centos.org/pipermail/centos-announce/2018-January/022708.html CEBA-2018:0042]<br />
* linux-firmware Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022698.html CESA-2018:0014]<br />
* qemu-kvm Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022705.html CESA-2018:0023]<br />
* libvirt Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022704.html CESA-2018:0029]<br />
<br />
CentOS 6:<br />
<br />
* kernel Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022701.html CESA-2018:0008]<br />
* microcode_ctl Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022700.html CESA-2018:0013]<br />
* qemu-kvm Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022702.html CESA-2018:0024]<br />
* libvirt Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022703.html CESA-2018:0030]<br />
<br />
See further in the centos-announce Security mails for January<br />
[https://lists.centos.org/pipermail/centos-announce/2018-January/date.html https://lists.centos.org/pipermail/centos-announce/2018-January/date.html]<br />
<br />
==== Scientific Linux ====<br />
<br />
'''Important! [as of 18th January]'''<br />
<br />
Scientific Linux is following RedHat in the revert of the microcode_ctl package, see [https://www.scientificlinux.org/category/sl-errata/slsa-20180093-1/ https://www.scientificlinux.org/category/sl-errata/slsa-20180093-1/]<br />
<br />
<br><br />
<br />
* SL6: [https://www.scientificlinux.org/category/sl-errata/slsa-20180008-1/ https://www.scientificlinux.org/category/sl-errata/slsa-20180008-1/] <br />
* SL7: [https://www.scientificlinux.org/category/sl-errata/slsa-20180007-1/ https://www.scientificlinux.org/category/sl-errata/slsa-20180007-1/] <br />
<br />
<br> <br />
<br />
* SL6: <br />
** qemu-kvm: [http://scientificlinux.org/category/sl-errata/slsa-20180024-1/ http://scientificlinux.org/category/sl-errata/slsa-20180024-1/] <br />
** libvirt: [http://scientificlinux.org/category/sl-errata/slsa-20180030-1/ http://scientificlinux.org/category/sl-errata/slsa-20180030-1/] <br />
* SL7: <br />
** qemu-kvm: [http://scientificlinux.org/category/sl-errata/slsa-20180023-1/ http://scientificlinux.org/category/sl-errata/slsa-20180023-1/] <br />
** libvirt: [http://scientificlinux.org/category/sl-errata/slsa-20180029-1/ http://scientificlinux.org/category/sl-errata/slsa-20180029-1/] <br />
<br />
==== Ubuntu ====<br />
<br />
[https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown]<br />
<br />
==== Debian ====<br />
<br />
[https://security-tracker.debian.org/tracker/CVE-2017-5715 CVE-2017-5715]<br />
[https://security-tracker.debian.org/tracker/CVE-2017-5753 CVE-2017-5753]<br />
[https://security-tracker.debian.org/tracker/CVE-2017-5754 CVE-2017-5754]<br />
<br />
=== System Vendors ===<br />
==== Supermicro ====<br />
<br />
[https://www.supermicro.com/support/security_Intel-SA-00088.cfm https://www.supermicro.com/support/security_Intel-SA-00088.cfm]<br />
<br />
==== Dell ====<br />
<br />
'''Important! [as of 23rd January]'''<br />
<br />
Dell is advising that all customers and partners should not deploy the BIOS update for the Spectre vulnerability at this time due to Intel’s advisory acknowledging reboot issues and unpredictable system behaviour. <br />
<br />
[http://www.dell.com/support/contents/uk/en/ukbsdt1/article/product-support/self-support-knowledgebase/software-and-downloads/support-for-meltdown-and-spectre http://www.dell.com/support/contents/uk/en/ukbsdt1/article/product-support/self-support-knowledgebase/software-and-downloads/support-for-meltdown-and-spectre]<br />
<br />
<br />
[https://www.dell.com/support/article/uk/en/ukbsdt1/sln308588/microprocessor-side-channel-vulnerabilities-cve-2017-5715-cve-2017-5753-cve-2017-5754-impact-on-dell-emc-products-dell-enterprise-servers-storage-and-networking-?lang=en https://www.dell.com/support/article/uk/en/ukbsdt1/sln308588/microprocessor-side-channel-vulnerabilities-cve-2017-5715-cve-2017-5753-cve-2017-5754-impact-on-dell-emc-products-dell-enterprise-servers-storage-and-networking-?lang=en]<br />
<br />
Note this is changing rather frequently<br />
<br />
==== HPE ====<br />
<br />
[as of January 23]<br />
<br />
HPE has updated their advisory to note that "Marked impacted products with TBD for System ROM updates per Intel's guidance on microcode issues" - so following suit with DELL.<br />
<br />
[https://support.hpe.com/hpsc/doc/public/display?sp4ts.oid=null&docLocale=en_US&docId=emr_na-hpesbhf03805en_us https://support.hpe.com/hpsc/doc/public/display?sp4ts.oid=null&docLocale=en_US&docId=emr_na-hpesbhf03805en_us]<br />
<br />
==== Lenovo ====<br />
<br />
[as of January 23]<br />
<br />
Lenovo security advisory<br />
<br />
<br />
=== Hypervisors ===<br />
<br />
[https://support.lenovo.com/gb/en/solutions/len-18282 https://support.lenovo.com/gb/en/solutions/len-18282]<br />
==== Xen ====<br />
<br />
<br />
* [https://xenbits.xen.org/xsa/advisory-254.html https://xenbits.xen.org/xsa/advisory-254.html]<br />
* [https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/]<br />
* [https://wiki.xenproject.org/wiki/Xen_Project_Meltdown_and_Spectre_Technical_FAQ https://wiki.xenproject.org/wiki/Xen_Project_Meltdown_and_Spectre_Technical_FAQ]<br />
* [https://wiki.xenproject.org/wiki/Respond_to_Meltdown_and_Spectre https://wiki.xenproject.org/wiki/Respond_to_Meltdown_and_Spectre]<br />
<br />
==== QEMU-KVM ====<br />
<br />
In order to protect hypervisors from malicious VMs, the kernel, microcode and QEMU must be updated:<br />
<br />
[https://www.qemu.org/2018/01/04/spectre/ https://www.qemu.org/2018/01/04/spectre/]</div>Kourilhttps://wiki.egi.eu/w/index.php?title=SVG:Meltdown_and_Spectre_Vulnerabilities&diff=98478SVG:Meltdown and Spectre Vulnerabilities2018-02-02T13:08:31Z<p>Kouril: </p>
<hr />
<div>{{svg-header}} <br />
<br />
== Purpose of this page ==<br />
<br />
To provide more detailed information about the Meltdown and Spectre vulnerabilities, to complement the advisory, [[SVG:Advisory-SVG-CVE-2017-5753]].<br />
<br />
We are continuing to add new information when we become aware of it, and the situation continues to change (02nd February 2018). <br />
<br />
== What are they? ==<br />
<br />
These are vulnerabilities in the design of the chip hardware, and cannot be fully resolved by patching operating systems. However patches are available which mitigate these problems.<br />
* Meltdown (CVE-2017-5754) affects most Intel chips.<br />
* Spectre (CVE-2017-5753 and CVE-2017-5715) affects a wide range of chips.<br />
<br />
For more details, see [https://meltdownattack.com/ https://meltdownattack.com/ ], [https://spectreattack.com/ https://spectreattack.com/] and [https://googleprojectzero.blogspot.dk/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.dk/2018/01/reading-privileged-memory-with-side.html] <br />
<br />
== How to mitigate these vulnerabilities ==<br />
<br />
Each CVE can be mitigated via different ways:<br />
* Meltdown (CVE-2017-5754) can be mitigated via [https://en.wikipedia.org/wiki/Kernel_page-table_isolation Kernel Page Table Isolation], which is enabled by default in latest linux kernels<br />
* Spectre Variant 1 (CVE-2017-5753) has to be mitigated in each software which can be vulnerable. The latest linux kernel contains fixes to protect itself (does not protect other software).<br />
* Spectre Variant 2 (CVE-2017-5715) can be (at least partially) mitigated via at least two different approach:<br />
** Using new Intel-specific MSR, added via a microcode update, to control indirect branch restricted speculation (IBRS): Both a kernel and a microcode update are required. In addition, in case of virtualization, an update of the virtualization software (e.g. qemu & virt) is required to expose the new MSR to the VM.<br />
** Using "retpoline", a new software construct that can mitigate, on most CPUs, the vulnerability<br />
<br />
=== RedHat ===<br />
<br />
As of Feb 2nd 2018, RedHat has [https://access.redhat.com/security/vulnerabilities/speculativeexecution offered new kernel updates that can mitigate Meltdown (CVE-2017-5754), Spectre Variant 1 (CVE-2017-5753) and Spectre Variant 2 (CVE-2017-5715)].<br />
<br />
However, due to instability issues, it has [https://access.redhat.com/errata/RHSA-2018:0093 removed the microcode updates required for Spectre Variant 2 (CVE-2017-5715)]. Until Intel releases stable microcode or RedHat switches to 'retpoline', no mitigation for Spectre Variant 2 (CVE-2017-5715) is safely usable.<br />
<br />
It is currently possible to mitigate Meltdown (CVE-2017-5754) and Spectre Variant 1 (CVE-2017-5753) by:<br />
* On RHEL7: Updating the kernel to 3.10.0-693.11.6.el7, see [https://access.redhat.com/errata/RHSA-2018:0007 RHSA-2018:0007]<br />
* On RHEL6: Updating the kernel to 2.6.32-696.18.7.el6, see [https://access.redhat.com/errata/RHSA-2018:0008 RHSA-2018:0008]<br />
<br />
=== Centos ===<br />
<br />
Centos is following RedHat (see above).<br />
<br />
It is currently possible to mitigate Meltdown (CVE-2017-5754) and Spectre Variant 1 (CVE-2017-5753) by:<br />
* On Centos 7: Updating the kernel to 3.10.0-693.11.6.el7, see [https://lists.centos.org/pipermail/centos-announce/2018-January/022696.html CESA-2018:0007]<br />
* On Centos 6: Updating the kernel to 2.6.32-696.18.7.el6, see [https://lists.centos.org/pipermail/centos-announce/2018-January/022701.html CESA-2018:0008]<br />
<br />
=== Scientific Linux ===<br />
<br />
Scientific Linux is following RedHat (see above).<br />
<br />
It is currently possible to mitigate Meltdown (CVE-2017-5754) and Spectre Variant 1 (CVE-2017-5753) by:<br />
* On SL7: Updating the kernel to 3.10.0-693.11.6.el7, see [https://www.scientificlinux.org/category/sl-errata/slsa-20180007-1/ SLSA-2018:0007-1]<br />
* On SL6: Updating the kernel to 2.6.32-696.18.7.el6, see [https://www.scientificlinux.org/category/sl-errata/slsa-20180008-1/ SLSA-2018:0008-1]<br />
<br />
Additional details as well as information on other systems and platforms can be found in the next section.<br />
<br />
== More Information ==<br />
<br />
=== Relevant Advisories ===<br />
==== CERN ====<br />
<br />
CERN has compiled information which is useful for many EGI sites:<br />
<br />
[https://security.web.cern.ch/security/advisories/spectre-meltdown/spectre-meltdown.shtml https://security.web.cern.ch/security/advisories/spectre-meltdown/spectre-meltdown.shtml]<br />
<br />
==== Intel ====<br />
<br />
Intel has initially, on January 8th, [https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File released new microcodes] to complement the IBRS kernel patchset. However, these new microcodes are in fact '''unstable''' and Intel has since then recommended to stop deploying them.<br />
<br />
Intel latest recommendation can be found in their advisory, [https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr INTEL-SA-00088]<br />
<br />
More updates and information:<br />
* [https://newsroom.intel.com/news/intel-responds-to-security-research-findings/ Jan 3rd: Initial response]<br />
* [https://newsroom.intel.com/news-releases/intel-issues-updates-protect-systems-security-exploits/ Jan 4th]<br />
* [https://newsroom.intel.com/news/intel-offers-security-issue-update/ Jan 9th: Microcode released]<br />
* [https://newsroom.intel.com/editorials/intel-security-issue-update-initial-performance-data-results-client-systems/ Jan 10th: performance impact analysis]<br />
* [https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/ Jan 11th: Microcode unstability reported]<br />
* [https://newsroom.intel.com/news/firmware-updates-and-initial-performance-data-for-data-center-systems/ Jan 17th]<br />
* [https://newsroom.intel.com/news/root-cause-of-reboot-issue-identified-updated-guidance-for-customers-and-partners/ Jan 22th: Instabilities causes found for 2 Intel series]<br />
<br />
=== Linux Distributions ===<br />
==== RedHat ====<br />
<br />
'''Important! [as of 17th January]'''<br />
<br />
RedHat has issued new microcode_ctl packages to rollback the latest updates, see [https://access.redhat.com/errata/RHSA-2018:0093 RHSA-2018:0093].<br />
<br />
<br> <br />
<br />
RedHat description: <br />
* [https://access.redhat.com/security/vulnerabilities/speculativeexecution https://access.redhat.com/security/vulnerabilities/speculativeexecution]<br />
* [https://access.redhat.com/articles/3307751 https://access.redhat.com/articles/3307751 (subscription required)]<br />
* [https://access.redhat.com/solutions/3315431 https://access.redhat.com/solutions/3315431 (subscription required)]<br />
<br />
RedHat CVE info:<br />
* [https://access.redhat.com/security/cve/CVE-2017-5754 CVE-2017-5754] <br />
* [https://access.redhat.com/security/cve/CVE-2017-5753 CVE-2017-5753] <br />
* [https://access.redhat.com/security/cve/CVE-2017-5715 CVE-2017-5715]<br />
<br />
==== CentOS ====<br />
<br />
'''Important! [as of 17th January]'''<br />
<br />
Centos seems to be following Redhat in the revert of the microcode_ctl package, see [https://git.centos.org/blob/rpms!microcode_ctl.git/c7/SOURCES!disclaimer the disclaimer in the sources of the last package]<br />
<br />
<br><br />
<br />
CentOS 7:<br />
<br />
* kernel Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022696.html CESA-2018:0007]<br />
* microcode_ctl Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022697.html CESA-2018:0012] <br> also needs dracut BugFix Update for AMD: [https://lists.centos.org/pipermail/centos-announce/2018-January/022708.html CEBA-2018:0042]<br />
* linux-firmware Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022698.html CESA-2018:0014]<br />
* qemu-kvm Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022705.html CESA-2018:0023]<br />
* libvirt Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022704.html CESA-2018:0029]<br />
<br />
CentOS 6:<br />
<br />
* kernel Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022701.html CESA-2018:0008]<br />
* microcode_ctl Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022700.html CESA-2018:0013]<br />
* qemu-kvm Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022702.html CESA-2018:0024]<br />
* libvirt Security Update: [https://lists.centos.org/pipermail/centos-announce/2018-January/022703.html CESA-2018:0030]<br />
<br />
See further in the centos-announce Security mails for January<br />
[https://lists.centos.org/pipermail/centos-announce/2018-January/date.html https://lists.centos.org/pipermail/centos-announce/2018-January/date.html]<br />
<br />
==== Scientific Linux ====<br />
<br />
'''Important! [as of 18th January]'''<br />
<br />
Scientific Linux is following RedHat in the revert of the microcode_ctl package, see [https://www.scientificlinux.org/category/sl-errata/slsa-20180093-1/ https://www.scientificlinux.org/category/sl-errata/slsa-20180093-1/]<br />
<br />
<br><br />
<br />
* SL6: [https://www.scientificlinux.org/category/sl-errata/slsa-20180008-1/ https://www.scientificlinux.org/category/sl-errata/slsa-20180008-1/] <br />
* SL7: [https://www.scientificlinux.org/category/sl-errata/slsa-20180007-1/ https://www.scientificlinux.org/category/sl-errata/slsa-20180007-1/] <br />
<br />
<br> <br />
<br />
* SL6: <br />
** qemu-kvm: [http://scientificlinux.org/category/sl-errata/slsa-20180024-1/ http://scientificlinux.org/category/sl-errata/slsa-20180024-1/] <br />
** libvirt: [http://scientificlinux.org/category/sl-errata/slsa-20180030-1/ http://scientificlinux.org/category/sl-errata/slsa-20180030-1/] <br />
* SL7: <br />
** qemu-kvm: [http://scientificlinux.org/category/sl-errata/slsa-20180023-1/ http://scientificlinux.org/category/sl-errata/slsa-20180023-1/] <br />
** libvirt: [http://scientificlinux.org/category/sl-errata/slsa-20180029-1/ http://scientificlinux.org/category/sl-errata/slsa-20180029-1/] <br />
<br />
==== Ubuntu ====<br />
<br />
[https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown]<br />
<br />
==== Debian ====<br />
<br />
=== System Vendors ===<br />
==== Supermicro ====<br />
<br />
[https://www.supermicro.com/support/security_Intel-SA-00088.cfm https://www.supermicro.com/support/security_Intel-SA-00088.cfm]<br />
<br />
==== Dell ====<br />
<br />
'''Important! [as of 23rd January]'''<br />
<br />
Dell is advising that all customers and partners should not deploy the BIOS update for the Spectre vulnerability at this time due to Intel’s advisory acknowledging reboot issues and unpredictable system behaviour. <br />
<br />
[http://www.dell.com/support/contents/uk/en/ukbsdt1/article/product-support/self-support-knowledgebase/software-and-downloads/support-for-meltdown-and-spectre http://www.dell.com/support/contents/uk/en/ukbsdt1/article/product-support/self-support-knowledgebase/software-and-downloads/support-for-meltdown-and-spectre]<br />
<br />
<br />
[https://www.dell.com/support/article/uk/en/ukbsdt1/sln308588/microprocessor-side-channel-vulnerabilities-cve-2017-5715-cve-2017-5753-cve-2017-5754-impact-on-dell-emc-products-dell-enterprise-servers-storage-and-networking-?lang=en https://www.dell.com/support/article/uk/en/ukbsdt1/sln308588/microprocessor-side-channel-vulnerabilities-cve-2017-5715-cve-2017-5753-cve-2017-5754-impact-on-dell-emc-products-dell-enterprise-servers-storage-and-networking-?lang=en]<br />
<br />
Note this is changing rather frequently<br />
<br />
==== HPE ====<br />
<br />
[as of January 23]<br />
<br />
HPE has updated their advisory to note that "Marked impacted products with TBD for System ROM updates per Intel's guidance on microcode issues" - so following suit with DELL.<br />
<br />
[https://support.hpe.com/hpsc/doc/public/display?sp4ts.oid=null&docLocale=en_US&docId=emr_na-hpesbhf03805en_us https://support.hpe.com/hpsc/doc/public/display?sp4ts.oid=null&docLocale=en_US&docId=emr_na-hpesbhf03805en_us]<br />
<br />
==== Lenovo ====<br />
<br />
[as of January 23]<br />
<br />
Lenovo security advisory<br />
<br />
<br />
=== Hypervisors ===<br />
<br />
[https://support.lenovo.com/gb/en/solutions/len-18282 https://support.lenovo.com/gb/en/solutions/len-18282]<br />
==== Xen ====<br />
<br />
<br />
* [https://xenbits.xen.org/xsa/advisory-254.html https://xenbits.xen.org/xsa/advisory-254.html]<br />
* [https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/]<br />
* [https://wiki.xenproject.org/wiki/Xen_Project_Meltdown_and_Spectre_Technical_FAQ https://wiki.xenproject.org/wiki/Xen_Project_Meltdown_and_Spectre_Technical_FAQ]<br />
* [https://wiki.xenproject.org/wiki/Respond_to_Meltdown_and_Spectre https://wiki.xenproject.org/wiki/Respond_to_Meltdown_and_Spectre]<br />
<br />
==== QEMU-KVM ====<br />
<br />
In order to protect hypervisors from malicious VMs, the kernel, microcode and QEMU must be updated:<br />
<br />
[https://www.qemu.org/2018/01/04/spectre/ https://www.qemu.org/2018/01/04/spectre/]</div>Kourilhttps://wiki.egi.eu/w/index.php?title=File:Report-venom.pdf&diff=92451File:Report-venom.pdf2017-01-11T16:27:10Z<p>Kouril: uploaded a new version of &quot;File:Report-venom.pdf&quot;</p>
<hr />
<div></div>Kourilhttps://wiki.egi.eu/w/index.php?title=Venom_Rootkit&diff=92450Venom Rootkit2017-01-11T15:46:25Z<p>Kouril: </p>
<hr />
<div>EGI CSIRT performed a detailed analysis of Linux rootkit, which enables the attacker to maintain unauthorized access to compromised Linux systems. The rootkit was titled VENOM, referring to a term often used in the internal protocol implemented in the malware.<br />
<br />
More information is provided in a [https://wiki.egi.eu/w/images/c/ce/Report-venom.pdf detailed report].</div>Kourilhttps://wiki.egi.eu/w/index.php?title=Venom_Rootkit&diff=92449Venom Rootkit2017-01-11T15:46:09Z<p>Kouril: </p>
<hr />
<div>EGI CSIRT performed a detailed analysis of Linux rootkit, which enables to maintain unauthorized access to compromised Linux systems. The rootkit was titled VENOM, referring to a term often used in the internal protocol implemented in the malware.<br />
<br />
More information is provided in a [https://wiki.egi.eu/w/images/c/ce/Report-venom.pdf detailed report].</div>Kourilhttps://wiki.egi.eu/w/index.php?title=File:Report-venom.pdf&diff=92448File:Report-venom.pdf2017-01-11T15:41:22Z<p>Kouril: </p>
<hr />
<div></div>Kourilhttps://wiki.egi.eu/w/index.php?title=Venom_Rootkit&diff=92447Venom Rootkit2017-01-11T15:38:08Z<p>Kouril: </p>
<hr />
<div>EGI CSIRT performed a detailed analysis of Linux rootkit, which enables to maintain unauthorized access to compromised Linux systems. The rootkit was titled VENOM, referring to a term often used in the internal protocol implemented in the malware.<br />
<br />
The full report can be found in:<br />
[[File:report-venom.pdf]]</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI_CSIRT:Monitoring&diff=81956EGI CSIRT:Monitoring2015-07-20T07:20:23Z<p>Kouril: /* Pakiti client */</p>
<hr />
<div>{{Egi-csirt-header}}<br />
<br />
= About EGI-CSIRT Security monitoring activities =<br />
<br />
See the description of the [[EGI_CSIRT:SMG|Security Monitoring Group]] for general description of the activity.<br />
<br />
= Security monitoring with Nagios =<br />
<br />
* [[EGI_CSIRT:Monitoring:NagiosInstallationGuide|Installation guide for NGI level (security monitoring) Nagios]]<br />
<br />
= Pakiti =<br />
<br />
[https://github.com/CESNET/pakiti2 Pakiti] is a client-server tool to collect and evaluate data about packages installed on Linux machines, primarily meant to identify vulnerable SW that have not been properly updated. The EGI CSIRT operates the [[EGI_CSIRT:Monitoring:EGIPakiti|EGI Pakiti instance]] that is used to monitor the state of the EGI sites.<br />
<br />
Currently we are working on the new version of the Pakiti v3, more information for developers is available [[EGI_CSIRT:Monitoring:Pakitiv3|here]].<br />
<br />
== Pakiti client ==<br />
<br />
=== How to use the service? ===<br />
<br />
Pakiti is used by EGI CSIRT and can be used by any EGI site for additional checks. The documentation for client installation [[EGI_CSIRT:Pakiti_client|is available]].</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI_CSIRT:Monitoring&diff=81955EGI CSIRT:Monitoring2015-07-20T07:18:40Z<p>Kouril: /* How to use the service? */</p>
<hr />
<div>{{Egi-csirt-header}}<br />
<br />
= About EGI-CSIRT Security monitoring activities =<br />
<br />
See the description of the [[EGI_CSIRT:SMG|Security Monitoring Group]] for general description of the activity.<br />
<br />
= Security monitoring with Nagios =<br />
<br />
* [[EGI_CSIRT:Monitoring:NagiosInstallationGuide|Installation guide for NGI level (security monitoring) Nagios]]<br />
<br />
= Pakiti =<br />
<br />
[https://github.com/CESNET/pakiti2 Pakiti] is a client-server tool to collect and evaluate data about packages installed on Linux machines, primarily meant to identify vulnerable SW that have not been properly updated. The EGI CSIRT operates the [[EGI_CSIRT:Monitoring:EGIPakiti|EGI Pakiti instance]] that is used to monitor the state of the EGI sites.<br />
<br />
Currently we are working on the new version of the Pakiti v3, more information for developers is available [[EGI_CSIRT:Monitoring:Pakitiv3|here]].<br />
<br />
== Pakiti client ==<br />
<br />
=== How to use the service? ===<br />
<br />
Pakiti is used by EGI CSIRT and can be used by any EGI site for additional checks. The documentation for client installation [[EGI_CSIRT:Pakiti_client|is available]].<br />
<br />
=== Monitoring process ===<br />
<br />
Everytime the Pakiti client is executed it sends data to the Pakiti server where the data are immediately processed. The host reports are purged every day, so if the site should be monitored continuously Pakiti client has to be executed every day. It's good to spread execution of the Pakiti client in time to not overload the Pakiti server. Pakiti server updates its internal database of vulnerabilities once a day.</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI_CSIRT:Monitoring:EGIPakiti&diff=81954EGI CSIRT:Monitoring:EGIPakiti2015-07-20T07:18:07Z<p>Kouril: </p>
<hr />
<div>{{ Egi-csirt-dissemination-header}}<br />
EGI Pakiti gathers list of installed packages from selected worker nodes from all sites in the EGI using Pakiti client, which is run by the Nagios probe. Pakiti client also reports host name, running kernel and its site name. Because Nagios probes run on randomly selected worker node of the site, Pakiti purges every night reports older than one day. <br />
<br />
Pakiti has implemented ACL, so only administrators (members of EGI CSIRT team) can view and change everything in the Pakiti GUI. List of administrators is automatically synchronized with EGI SSO, only members of the EGI CSIRT team can be the administrator. Site security-officers can only view results regarding their site. List of security-officers is synchronized every night with the GOCDB.<br />
<br />
EGI CSIRT collects data from EGI sites regularly using a dedicated Nagios probe. A site can also deploy their [[EGI_CSIRT:Pakiti_client|own instance of Pakiti client]].<br />
<br />
== Views ==<br />
* '''Sites''' (default) - list of all monitored sites. List includes site name, country, number of hosts currently stored in the Pakiti DB and statistical data about average and worst number of unpatched packaged according to the security repository and CVEs. View can be filtered by the country. Site name is a link to the detailed view on the hosts from this site.<br />
<br />
* '''Hosts''' - shows all hosts currently stored in the Pakiti DB. View can be sorted by the tag, host name, time of report, running kernel and OS. <br />
<br />
* '''Hosts by tag''' - shows hosts, which have installed package vulnerable to the CVE, which was tagged by the EGI CSIRT team. Tags can be EGI-Critical, EGI-High, Critical, Warning. Tags with prefix EGI has impact on the EGI infrastructure. By default the view shows all tags.<br />
<br />
* '''Hosts by package''' - this view can show all hosts, which have installed particular package. View can be filtered by the site name.<br />
<br />
* '''CVE by site''' - this view can show all hosts, which have package which is vulnerable to the selected CVE. View can be filtered by host architecture, RedHat release and site name.<br />
<br />
* '''CVE''' - everywhere in the Pakiti, if you see the CVE, you can click and will see the list of packages and versions which are affected by the CVE. The view also provides link to the RedHat Bugzilla for the CVE.<br />
<br />
== Configuration ==<br />
<br />
* '''Settings''' - currently quite complicated, so leave it on Michal:-)<br />
* '''Exceptions''' - If some local administrator compile its own package and leave the version of the package untouched (only add some additional text), the package will be marked as vulnerable. On this page exceptions can be defined. Select the CVE and the tick the package, which contains the fix, this package will be omitted from the listing of the CVEs.<br />
* '''CVE Tags''' - On this page, the CVE can be tagged as EGI-Critical, EGI-High, Critical or Warning. Tags prefixed with EGI has impact on the EGI infrastructure. <br />
* '''ACL''' - This page is divided into two parts. First shows list of persons, who have access to the particular site. This list is automatically synchronized with the GOCDB, but entries can be added manually. You have to provide user name, DN of the certificate in format '/C=bla/O=bla/...' and select site. The second part of the page contains list of DNs of Pakiti administrators, should be the same list as EGI CSIRT members.<br />
<br />
== Alternative views ==<br />
<br />
* '''Hosts by tag''' - (https://pakiti.egi.eu/api/tags_sites.php) results are identical to the Hosts by tag, but the output can be in CSV or XML. Output can be filtered using these options:<br />
''tag'' - EGI-Critical or EGI-High<br />
''country'' - name of the country<br />
''site'' - name of the site<br />
''cve'' - CVE name<br />
''type'' - csv (default) or xml (xsd is available at http://pakiti.egi.eu/pakiti.xsd)<br />
<br />
Example: https://pakiti.egi.eu/api/tags_sites.php?tag=EGI-Critical&site=CBPF&cve=CVE-2009-3547<br />
<br />
* '''CVE statistics''' - (https://pakiti.egi.eu/api/cve_stats.php) shows list of sites vulnerable to the CVEs tagged as EGI-Critical from the beginning of the November 2010. Output can be filtered using these options:<br />
''tag'' - EGI-Critical or EGI-High<br />
''country'' - name of the country<br />
''site'' - name of the site<br />
''cve'' - CVE name<br />
''type'' - csv (default) or xml (xsd is available at http://pakiti.egi.eu/pakiti.xsd)<br />
''from_date'' - set the start date<br />
''to_date'' - set the end date<br />
<br />
Example: https://pakiti.egi.eu/api/cve_stats.php?tag=EGI-Critical&from_date=2010-11-30</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI_CSIRT:Monitoring&diff=81953EGI CSIRT:Monitoring2015-07-20T07:13:54Z<p>Kouril: </p>
<hr />
<div>{{Egi-csirt-header}}<br />
<br />
= About EGI-CSIRT Security monitoring activities =<br />
<br />
See the description of the [[EGI_CSIRT:SMG|Security Monitoring Group]] for general description of the activity.<br />
<br />
= Security monitoring with Nagios =<br />
<br />
* [[EGI_CSIRT:Monitoring:NagiosInstallationGuide|Installation guide for NGI level (security monitoring) Nagios]]<br />
<br />
= Pakiti =<br />
<br />
[https://github.com/CESNET/pakiti2 Pakiti] is a client-server tool to collect and evaluate data about packages installed on Linux machines, primarily meant to identify vulnerable SW that have not been properly updated. The EGI CSIRT operates the [[EGI_CSIRT:Monitoring:EGIPakiti|EGI Pakiti instance]] that is used to monitor the state of the EGI sites.<br />
<br />
Currently we are working on the new version of the Pakiti v3, more information for developers is available [[EGI_CSIRT:Monitoring:Pakitiv3|here]].<br />
<br />
== Pakiti client ==<br />
<br />
=== How to use the service? ===<br />
<br />
Pakiti is used by EGI CSIRT and can be used by any EGI site for additional checks. The documentation for client installation is available from [[EGI_CSIRT:Pakiti_client]].<br />
<br />
=== Monitoring process ===<br />
<br />
Everytime the Pakiti client is executed it sends data to the Pakiti server where the data are immediately processed. The host reports are purged every day, so if the site should be monitored continuously Pakiti client has to be executed every day. It's good to spread execution of the Pakiti client in time to not overload the Pakiti server. Pakiti server updates its internal database of vulnerabilities once a day.</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI_CSIRT:Pakiti_client&diff=81952EGI CSIRT:Pakiti client2015-07-20T07:09:18Z<p>Kouril: </p>
<hr />
<div>The pakiti-client can be used to send package informations to pakiti.egi.eu.<br />
<br />
If you have the proper credentials in GOC-DB and submit your report with the correct SITE_NAME, you, your NGI-CSIRT and the EGI-CSIRT will be able to monitor the packages installed on your hosts and potentially vulnerabilities. The results can be accessed at https://pakiti.egi.eu.<br />
<br />
<br />
== Manual Installation ==<br />
<br />
=== Installing the Pakiti client ===<br />
<br />
The pakiti client is now available from EPEL.<br />
If your machine already has EPEL enabled, the following command is enough to install it:<br />
<br />
<nowiki>yum install pakiti-client</nowiki><br />
<br />
=== Configuring the Pakiti client for EGI ===<br />
<br />
In addition to this package, a configuration file corresponding to the EGI server must be created.<br />
<br />
==== Using wget (unsafe) ====<br />
<br />
You can get the configuration via http (thus unsafe) with the following wget:<br />
<br />
<nowiki>wget http://pakiti.egi.eu/egi-package-reporter.conf -O /etc/egi-package-reporter.conf</nowiki><br />
<br />
==== Copy/paste ====<br />
<br />
The current recommended way of getting the configuration is simply to past the following line in a shell:<br />
<br />
<nowiki>cat <<EOF > /etc/egi-package-reporter.conf<br />
#<br />
# pakiti-client configuration file to submit the list of installed<br />
# packages to the EGI Pakiti<br />
#<br />
<br />
url = http://pakiti.egi.eu:80/feed/<br />
expect = 200 OK<br />
encrypt = <<EOT<br />
-----BEGIN CERTIFICATE-----<br />
MIIEMTCCAxmgAwIBAgIIMzVxgpqOq7wwDQYJKoZIhvcNAQEFBQAwWTESMBAGCgmS<br />
JomT8ixkARkWAmN6MRkwFwYKCZImiZPyLGQBGRYJY2VzbmV0LWNhMRIwEAYDVQQK<br />
DAlDRVNORVQgQ0ExFDASBgNVBAMMC0NFU05FVCBDQSAzMB4XDTEzMDkyNTEzMzgy<br />
MVoXDTE0MTAyNTEzMzgyMVowWDESMBAGCgmSJomT8ixkARkWAmN6MRkwFwYKCZIm<br />
iZPyLGQBGRYJY2VzbmV0LWNhMQ8wDQYDVQQKDAZDRVNORVQxFjAUBgNVBAMMDXBh<br />
a2l0aS5lZ2kuZXUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDbho74<br />
s32hfdcWfxle02AxWbunSnCaKuqK4S5BFhxHUbBo74LpvLw0VMaaxyQmya3O1TEu<br />
xWKjJlqFS5Evm+t8w/7NyTcbZvnCXmDopxEX9HlDRsVVSH1tQNy79iZpjmQboZhP<br />
ueRQhPsfm5b0NJuLnPjHq03JFBk7FASt7BWkJtcAQPV9Q3x/vw3780KEUoADfmIB<br />
lOnOmzoUoKT6pfxRf4iORnDhbaeApMI5PGbyMRmbzfS4Prh7w7vorG0fhRfydq0G<br />
hYOY0+kvNbbt/hH4XDcO0zeAA4E6w30Yr1DYX2VXkc/RCO/LqvGjZzZW9ZW/kquP<br />
woOWxyLaQ27Hu7RBAgMBAAGjgf0wgfowHQYDVR0OBBYEFGT5cZ2TnPXqdPpshKDx<br />
xit+R5MeMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAU9V0/vJiZix/xSOf+R4dx<br />
CaLcukUwJwYDVR0gBCAwHjAMBgoqhkiG90wFAgIBMA4GDCsGAQQBvnkBAgIDATA4<br />
BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNlc25ldC1jYS5jei9DRVNORVRf<br />
Q0FfMy5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr<br />
BgEFBQcDAjAYBgNVHREEETAPgg1wYWtpdGkuZWdpLmV1MA0GCSqGSIb3DQEBBQUA<br />
A4IBAQB7OahKWgwgNn9Nv9fOt/H2L2G1WbwUlmF2xIiFWiXs8MKzshLL5qrlhBfc<br />
KxNe+EptPzfpBOEWYiBPmPq3hXKRxeCg8kjHhijSHDy9rOqZdfTN5Jf4fGqB0SIC<br />
2YVWg9vR7kJha+BnEogZooJhVKpDJjnEKCGST+QHUDfIfB1pk2XqM1dYvgt8Ee8v<br />
cuRMJY1XiE0YKFg9ZLEtlbVLYFUfM877RKaZTVxh2L5bE7pFWAY3n0LJGNpYucr6<br />
6uCgpre94eEW9/MBsDKkrq8d1TDTXrQ0dMlBZtzWFTSNy8oYxUMqTGk5Vj7y88Pp<br />
wAUTiDVs/PjwwQqTz80tUXMe1EC/<br />
-----END CERTIFICATE-----<br />
EOT<br />
EOF</nowiki><br />
<br />
<br />
=== Running the Pakiti client for EGI ===<br />
<br />
With the package and the configuration, the following commands will run the pakiti-client and transmit all its data to the EGI CSIRT pakiti instance!<br />
<br />
<nowiki>pakiti-client --site SITE_NAME --conf /etc/egi-package-reporter.conf</nowiki><br />
<br />
'''<span style="color:#FF0000"> Please remember to replace SITE_NAME by your actual site name </span> '''<br />
<br />
=== Running the Pakiti client for EGI every day via cron ===<br />
<br />
You can also run pakiti-client as a daily cronjob, in order to send us data every days.<br />
In that case, please randomize as much as possible the cronjob between your hosts.<br />
Please also note that the pakiti-client can run as nobody.<br />
<br />
You can enable it by running, for example (be sure to reload your cron daemon afterwards):<br />
<nowiki>echo "$(perl -e 'print int(rand(60))') $(perl -e 'print int(rand(24))') * * * nobody /usr/bin/pakiti-client --site SITE_NAME --conf /etc/egi-package-reporter.conf" > /etc/cron.d/pakiti-egi</nowiki><br />
<br />
'''<span style="color:#FF0000"> Please remember to replace SITE_NAME by your actual site name </span> '''<br />
== Puppet Installation ==<br />
<br />
The simplest way to configure and run the pakiti-client on a cluster is to use puppet:<br />
You just need to create a file and a manifest.<br />
* Create a file named egi-package-reporter.conf in the 'files' folders of you configuration containing:<br />
<nowiki>#<br />
# pakiti-client configuration file to submit the list of installed<br />
# packages to the EGI Pakiti<br />
#<br />
<br />
url = http://pakiti.egi.eu:80/feed/<br />
expect = 200 OK<br />
encrypt = <<EOT<br />
-----BEGIN CERTIFICATE-----<br />
MIIEMTCCAxmgAwIBAgIIMzVxgpqOq7wwDQYJKoZIhvcNAQEFBQAwWTESMBAGCgmS<br />
JomT8ixkARkWAmN6MRkwFwYKCZImiZPyLGQBGRYJY2VzbmV0LWNhMRIwEAYDVQQK<br />
DAlDRVNORVQgQ0ExFDASBgNVBAMMC0NFU05FVCBDQSAzMB4XDTEzMDkyNTEzMzgy<br />
MVoXDTE0MTAyNTEzMzgyMVowWDESMBAGCgmSJomT8ixkARkWAmN6MRkwFwYKCZIm<br />
iZPyLGQBGRYJY2VzbmV0LWNhMQ8wDQYDVQQKDAZDRVNORVQxFjAUBgNVBAMMDXBh<br />
a2l0aS5lZ2kuZXUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDbho74<br />
s32hfdcWfxle02AxWbunSnCaKuqK4S5BFhxHUbBo74LpvLw0VMaaxyQmya3O1TEu<br />
xWKjJlqFS5Evm+t8w/7NyTcbZvnCXmDopxEX9HlDRsVVSH1tQNy79iZpjmQboZhP<br />
ueRQhPsfm5b0NJuLnPjHq03JFBk7FASt7BWkJtcAQPV9Q3x/vw3780KEUoADfmIB<br />
lOnOmzoUoKT6pfxRf4iORnDhbaeApMI5PGbyMRmbzfS4Prh7w7vorG0fhRfydq0G<br />
hYOY0+kvNbbt/hH4XDcO0zeAA4E6w30Yr1DYX2VXkc/RCO/LqvGjZzZW9ZW/kquP<br />
woOWxyLaQ27Hu7RBAgMBAAGjgf0wgfowHQYDVR0OBBYEFGT5cZ2TnPXqdPpshKDx<br />
xit+R5MeMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAU9V0/vJiZix/xSOf+R4dx<br />
CaLcukUwJwYDVR0gBCAwHjAMBgoqhkiG90wFAgIBMA4GDCsGAQQBvnkBAgIDATA4<br />
BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNlc25ldC1jYS5jei9DRVNORVRf<br />
Q0FfMy5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr<br />
BgEFBQcDAjAYBgNVHREEETAPgg1wYWtpdGkuZWdpLmV1MA0GCSqGSIb3DQEBBQUA<br />
A4IBAQB7OahKWgwgNn9Nv9fOt/H2L2G1WbwUlmF2xIiFWiXs8MKzshLL5qrlhBfc<br />
KxNe+EptPzfpBOEWYiBPmPq3hXKRxeCg8kjHhijSHDy9rOqZdfTN5Jf4fGqB0SIC<br />
2YVWg9vR7kJha+BnEogZooJhVKpDJjnEKCGST+QHUDfIfB1pk2XqM1dYvgt8Ee8v<br />
cuRMJY1XiE0YKFg9ZLEtlbVLYFUfM877RKaZTVxh2L5bE7pFWAY3n0LJGNpYucr6<br />
6uCgpre94eEW9/MBsDKkrq8d1TDTXrQ0dMlBZtzWFTSNy8oYxUMqTGk5Vj7y88Pp<br />
wAUTiDVs/PjwwQqTz80tUXMe1EC/<br />
-----END CERTIFICATE-----<br />
EOT</nowiki><br />
<br />
* Add to one of your manifest:<br />
<nowiki>package { 'pakiti-client':<br />
ensure => 'present',<br />
}<br />
file { /etc/egi-package-reporter.conf:<br />
mode => '0644',<br />
source => 'puppet:///path/to/egi-package-reporter.conf',<br />
}<br />
cron { 'pakiti-egi':<br />
ensure => 'present',<br />
command => 'pakiti-client --conf /etc/egi-package-reporter.conf --site SITE_NAME',<br />
user => 'nobody',<br />
hour => fqdn_rand(24),<br />
minute => fqdn_rand(60),<br />
}</nowiki><br />
<br />
'''<span style="color:#FF0000"> Please remember to replace SITE_NAME by your actual site name. </span>'''<br />
'''<span style="color:#FF0000"> Please remember to replace /path/to/egi-package-reporter.conf by your actual path to egi-package-reporter.conf.</span>'''</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI-InSPIRE:Software_Copyrights_and_Licenses&diff=76987EGI-InSPIRE:Software Copyrights and Licenses2015-02-11T14:58:29Z<p>Kouril: </p>
<hr />
<div>{{EGI-Inspire_menubar}} {{TOC_right}} <br />
<br />
The following gives an overview about copyright and licenses used and granted in the EGI-InSPIRE project. <br />
<br />
All work done for EGI-InSPIRE should include the following notice [[EGI-InSPIRE:License]] <br />
<br />
<br> <br />
<br />
{| border="1"<br />
|-<br />
! colspan="2" | Application / Tool <br />
! valign="top" rowspan="2" | Source Code Access <br />
! valign="top" rowspan="2" | Copyright <br />
! valign="top" rowspan="2" | License <br />
! valign="top" rowspan="2" | Remarks<br />
|-<br />
! EGI Application <br />
! 3<sup>rd</sup> party tool<br />
|- style="background:LightGray"<br />
| colspan="2" | Operation Portal (incl. Lavoisier) <br />
| SVN - git <br />
| CCIN2P3 <br />
| Apache 2.0 <br />
| <br><br />
|-<br />
| <br> <br />
| Symphony <br />
| SVN <br />
| Fabien Potencier <br />
| MIT license <br />
| Symphony in turn uses several 3<sup>rd</sup> party tools, which are licensed under MIT, LGPL, BSD and ICU licenses.<br />
|- style="background:LightGray"<br />
| colspan="2" | SAM/ARGO Framework <br />
| JIRA <br />
| the actual institutions who contributed <br />
| Apache 2 <br />
| <br><br />
|-<br />
| <br> <br />
| Nagios <br />
| <br> <br />
| Nagios Enterprises <br />
| http://www.nagios.com/legal/licenses/ <br />
| <br><br />
|- style="background:LightGray"<br />
| colspan="2" | GOCDB <br />
| SVN <br />
| Rutherford Appleton Laboratory, STFC, UK on behalf of EGI.eu. <br />
| gLite/Apache 2 (https://goc.gridops.org/portal/index.php?Page_Type=Static_HTML&amp;Page=Credits) <br />
| <br><br />
|- style="background:LightGray"<br />
| colspan="2" | Accounting Portal <br />
| SVN <br />
| CESGA <br />
| Apache2.0 <br />
| <br><br />
|- style="background:LightGray"<br />
| colspan="2" | Metrics Portal <br />
| SVN <br />
| CESGA <br />
| Apache2.0 <br />
| <br><br />
|- style="background:LightGray"<br />
| colspan="2" | <!--[if gte mso 9]><xml><br />
<o:OfficeDocumentSettings><br />
<o:AllowPNG/><br />
</o:OfficeDocumentSettings><br />
</xml><![endif]--><span>Message Broker Network</span><!--[if gte mso 9]><xml><br />
<w:WordDocument><br />
<w:View>Normal</w:View><br />
<w:Zoom>0</w:Zoom><br />
<w:TrackMoves/><br />
<w:TrackFormatting/><br />
<w:PunctuationKerning/><br />
<w:ValidateAgainstSchemas/><br />
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid><br />
<w:IgnoreMixedContent>false</w:IgnoreMixedContent><br />
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText><br />
<w:DoNotPromoteQF/><br />
<w:LidThemeOther>EN-GB</w:LidThemeOther><br />
<w:LidThemeAsian>X-NONE</w:LidThemeAsian><br />
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript><br />
<w:Compatibility><br />
<w:BreakWrappedTables/><br />
<w:SnapToGridInCell/><br />
<w:WrapTextWithPunct/><br />
<w:UseAsianBreakRules/><br />
<w:DontGrowAutofit/><br />
<w:SplitPgBreakAndParaMark/><br />
<w:EnableOpenTypeKerning/><br />
<w:DontFlipMirrorIndents/><br />
<w:OverrideTableStyleHps/><br />
</w:Compatibility><br />
<m:mathPr><br />
<m:mathFont m:val="Cambria Math"/><br />
<m:brkBin m:val="before"/><br />
<m:brkBinSub m:val="&#45;-"/><br />
<m:smallFrac m:val="off"/><br />
<m:dispDef/><br />
<m:lMargin m:val="0"/><br />
<m:rMargin m:val="0"/><br />
<m:defJc m:val="centerGroup"/><br />
<m:wrapIndent m:val="1440"/><br />
<m:intLim m:val="subSup"/><br />
<m:naryLim m:val="undOvr"/><br />
</m:mathPr></w:WordDocument><br />
</xml><![endif]--><!--[if gte mso 9]><xml><br />
<w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"<br />
DefSemiHidden="true" DefQFormat="false" DefPriority="99"<br />
LatentStyleCount="267"><br />
<w:LsdException Locked="false" Priority="0" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Normal"/><br />
<w:LsdException Locked="false" Priority="9" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="heading 1"/><br />
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/><br />
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/><br />
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/><br />
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/><br />
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/><br />
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/><br />
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/><br />
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 1"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 2"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 3"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 4"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 5"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 6"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 7"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 8"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 9"/><br />
<w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/><br />
<w:LsdException Locked="false" Priority="10" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Title"/><br />
<w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/><br />
<w:LsdException Locked="false" Priority="11" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/><br />
<w:LsdException Locked="false" Priority="22" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Strong"/><br />
<w:LsdException Locked="false" Priority="20" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/><br />
<w:LsdException Locked="false" Priority="59" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Table Grid"/><br />
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/><br />
<w:LsdException Locked="false" Priority="1" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/><br />
<w:LsdException Locked="false" Priority="60" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Shading"/><br />
<w:LsdException Locked="false" Priority="61" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light List"/><br />
<w:LsdException Locked="false" Priority="62" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Grid"/><br />
<w:LsdException Locked="false" Priority="63" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 1"/><br />
<w:LsdException Locked="false" Priority="64" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 2"/><br />
<w:LsdException Locked="false" Priority="65" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 1"/><br />
<w:LsdException Locked="false" Priority="66" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 2"/><br />
<w:LsdException Locked="false" Priority="67" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 1"/><br />
<w:LsdException Locked="false" Priority="68" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 2"/><br />
<w:LsdException Locked="false" Priority="69" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 3"/><br />
<w:LsdException Locked="false" Priority="70" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Dark List"/><br />
<w:LsdException Locked="false" Priority="71" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Shading"/><br />
<w:LsdException Locked="false" Priority="72" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful List"/><br />
<w:LsdException Locked="false" Priority="73" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Grid"/><br />
<w:LsdException Locked="false" Priority="60" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Shading Accent 1"/><br />
<w:LsdException Locked="false" Priority="61" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light List Accent 1"/><br />
<w:LsdException Locked="false" Priority="62" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Grid Accent 1"/><br />
<w:LsdException Locked="false" Priority="63" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/><br />
<w:LsdException Locked="false" Priority="64" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/><br />
<w:LsdException Locked="false" Priority="65" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/><br />
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/><br />
<w:LsdException Locked="false" Priority="34" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/><br />
<w:LsdException Locked="false" Priority="29" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Quote"/><br />
<w:LsdException Locked="false" Priority="30" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/><br />
<w:LsdException Locked="false" Priority="66" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/><br />
<w:LsdException Locked="false" Priority="67" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/><br />
<w:LsdException Locked="false" Priority="68" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/><br />
<w:LsdException Locked="false" Priority="69" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/><br />
<w:LsdException Locked="false" Priority="70" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Dark List Accent 1"/><br />
<w:LsdException Locked="false" Priority="71" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/><br />
<w:LsdException Locked="false" Priority="72" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful List Accent 1"/><br />
<w:LsdException Locked="false" Priority="73" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/><br />
<w:LsdException Locked="false" Priority="60" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Shading Accent 2"/><br />
<w:LsdException Locked="false" Priority="61" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light List Accent 2"/><br />
<w:LsdException Locked="false" Priority="62" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Grid Accent 2"/><br />
<w:LsdException Locked="false" Priority="63" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/><br />
<w:LsdException Locked="false" Priority="64" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/><br />
<w:LsdException Locked="false" Priority="65" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/><br />
<w:LsdException Locked="false" Priority="66" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/><br />
<w:LsdException Locked="false" Priority="67" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/><br />
<w:LsdException Locked="false" Priority="68" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/><br />
<w:LsdException Locked="false" Priority="69" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/><br />
<w:LsdException Locked="false" Priority="70" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Dark List Accent 2"/><br />
<w:LsdException Locked="false" Priority="71" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/><br />
<w:LsdException Locked="false" Priority="72" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful List Accent 2"/><br />
<w:LsdException Locked="false" Priority="73" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/><br />
<w:LsdException Locked="false" Priority="60" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Shading Accent 3"/><br />
<w:LsdException Locked="false" Priority="61" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light List Accent 3"/><br />
<w:LsdException Locked="false" Priority="62" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Grid Accent 3"/><br />
<w:LsdException Locked="false" Priority="63" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/><br />
<w:LsdException Locked="false" Priority="64" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/><br />
<w:LsdException Locked="false" Priority="65" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/><br />
<w:LsdException Locked="false" Priority="66" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/><br />
<w:LsdException Locked="false" Priority="67" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/><br />
<w:LsdException Locked="false" Priority="68" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/><br />
<w:LsdException Locked="false" Priority="69" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/><br />
<w:LsdException Locked="false" Priority="70" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Dark List Accent 3"/><br />
<w:LsdException Locked="false" Priority="71" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/><br />
<w:LsdException Locked="false" Priority="72" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful List Accent 3"/><br />
<w:LsdException Locked="false" Priority="73" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/><br />
<w:LsdException Locked="false" Priority="60" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Shading Accent 4"/><br />
<w:LsdException Locked="false" Priority="61" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light List Accent 4"/><br />
<w:LsdException Locked="false" Priority="62" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Grid Accent 4"/><br />
<w:LsdException Locked="false" Priority="63" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/><br />
<w:LsdException Locked="false" Priority="64" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/><br />
<w:LsdException Locked="false" Priority="65" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/><br />
<w:LsdException Locked="false" Priority="66" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/><br />
<w:LsdException Locked="false" Priority="67" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/><br />
<w:LsdException Locked="false" Priority="68" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/><br />
<w:LsdException Locked="false" Priority="69" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/><br />
<w:LsdException Locked="false" Priority="70" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Dark List Accent 4"/><br />
<w:LsdException Locked="false" Priority="71" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/><br />
<w:LsdException Locked="false" Priority="72" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful List Accent 4"/><br />
<w:LsdException Locked="false" Priority="73" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/><br />
<w:LsdException Locked="false" Priority="60" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Shading Accent 5"/><br />
<w:LsdException Locked="false" Priority="61" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light List Accent 5"/><br />
<w:LsdException Locked="false" Priority="62" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Grid Accent 5"/><br />
<w:LsdException Locked="false" Priority="63" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/><br />
<w:LsdException Locked="false" Priority="64" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/><br />
<w:LsdException Locked="false" Priority="65" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/><br />
<w:LsdException Locked="false" Priority="66" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/><br />
<w:LsdException Locked="false" Priority="67" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/><br />
<w:LsdException Locked="false" Priority="68" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/><br />
<w:LsdException Locked="false" Priority="69" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/><br />
<w:LsdException Locked="false" Priority="70" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Dark List Accent 5"/><br />
<w:LsdException Locked="false" Priority="71" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/><br />
<w:LsdException Locked="false" Priority="72" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful List Accent 5"/><br />
<w:LsdException Locked="false" Priority="73" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/><br />
<w:LsdException Locked="false" Priority="60" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Shading Accent 6"/><br />
<w:LsdException Locked="false" Priority="61" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light List Accent 6"/><br />
<w:LsdException Locked="false" Priority="62" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Grid Accent 6"/><br />
<w:LsdException Locked="false" Priority="63" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/><br />
<w:LsdException Locked="false" Priority="64" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/><br />
<w:LsdException Locked="false" Priority="65" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/><br />
<w:LsdException Locked="false" Priority="66" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/><br />
<w:LsdException Locked="false" Priority="67" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/><br />
<w:LsdException Locked="false" Priority="68" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/><br />
<w:LsdException Locked="false" Priority="69" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/><br />
<w:LsdException Locked="false" Priority="70" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Dark List Accent 6"/><br />
<w:LsdException Locked="false" Priority="71" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/><br />
<w:LsdException Locked="false" Priority="72" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful List Accent 6"/><br />
<w:LsdException Locked="false" Priority="73" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/><br />
<w:LsdException Locked="false" Priority="19" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/><br />
<w:LsdException Locked="false" Priority="21" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/><br />
<w:LsdException Locked="false" Priority="31" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/><br />
<w:LsdException Locked="false" Priority="32" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/><br />
<w:LsdException Locked="false" Priority="33" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Book Title"/><br />
<w:LsdException Locked="false" Priority="37" Name="Bibliography"/><br />
<w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/><br />
</w:LatentStyles><br />
</xml><![endif]--><!--[if gte mso 10]><br />
<style><br />
/* Style Definitions */<br />
table.MsoNormalTable<br />
{mso-style-name:"Table Normal";<br />
mso-tstyle-rowband-size:0;<br />
mso-tstyle-colband-size:0;<br />
mso-style-noshow:yes;<br />
mso-style-priority:99;<br />
mso-style-parent:"";<br />
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;<br />
mso-para-margin-top:0cm;<br />
mso-para-margin-right:0cm;<br />
mso-para-margin-bottom:8.0pt;<br />
mso-para-margin-left:0cm;<br />
line-height:107%;<br />
mso-pagination:widow-orphan;<br />
font-size:11.0pt;<br />
font-family:"Calibri","sans-serif";<br />
mso-ascii-font-family:Calibri;<br />
mso-ascii-theme-font:minor-latin;<br />
mso-hansi-font-family:Calibri;<br />
mso-hansi-theme-font:minor-latin;<br />
mso-fareast-language:EN-US;}<br />
</style><br />
<![endif]--> <br />
| <br> <br />
| GRNET<br> <br />
| Apache 2.0 <br />
| Based on 3rd party software <span> (</span><span>ActiveMQ)</span><br><br />
|- style="background:LightGray"<br />
| colspan="2" | <!--[if gte mso 9]><xml><br />
<o:OfficeDocumentSettings><br />
<o:AllowPNG/><br />
</o:OfficeDocumentSettings><br />
</xml><![endif]--><span>Pakiti</span><!--[if gte mso 9]><xml><br />
<w:WordDocument><br />
<w:View>Normal</w:View><br />
<w:Zoom>0</w:Zoom><br />
<w:TrackMoves/><br />
<w:TrackFormatting/><br />
<w:PunctuationKerning/><br />
<w:ValidateAgainstSchemas/><br />
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid><br />
<w:IgnoreMixedContent>false</w:IgnoreMixedContent><br />
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText><br />
<w:DoNotPromoteQF/><br />
<w:LidThemeOther>EN-GB</w:LidThemeOther><br />
<w:LidThemeAsian>X-NONE</w:LidThemeAsian><br />
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript><br />
<w:Compatibility><br />
<w:BreakWrappedTables/><br />
<w:SnapToGridInCell/><br />
<w:WrapTextWithPunct/><br />
<w:UseAsianBreakRules/><br />
<w:DontGrowAutofit/><br />
<w:SplitPgBreakAndParaMark/><br />
<w:EnableOpenTypeKerning/><br />
<w:DontFlipMirrorIndents/><br />
<w:OverrideTableStyleHps/><br />
</w:Compatibility><br />
<m:mathPr><br />
<m:mathFont m:val="Cambria Math"/><br />
<m:brkBin m:val="before"/><br />
<m:brkBinSub m:val="&#45;-"/><br />
<m:smallFrac m:val="off"/><br />
<m:dispDef/><br />
<m:lMargin m:val="0"/><br />
<m:rMargin m:val="0"/><br />
<m:defJc m:val="centerGroup"/><br />
<m:wrapIndent m:val="1440"/><br />
<m:intLim m:val="subSup"/><br />
<m:naryLim m:val="undOvr"/><br />
</m:mathPr></w:WordDocument><br />
</xml><![endif]--><!--[if gte mso 9]><xml><br />
<w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"<br />
DefSemiHidden="true" DefQFormat="false" DefPriority="99"<br />
LatentStyleCount="267"><br />
<w:LsdException Locked="false" Priority="0" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Normal"/><br />
<w:LsdException Locked="false" Priority="9" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="heading 1"/><br />
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/><br />
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/><br />
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/><br />
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/><br />
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/><br />
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/><br />
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/><br />
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 1"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 2"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 3"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 4"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 5"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 6"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 7"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 8"/><br />
<w:LsdException Locked="false" Priority="39" Name="toc 9"/><br />
<w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/><br />
<w:LsdException Locked="false" Priority="10" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Title"/><br />
<w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/><br />
<w:LsdException Locked="false" Priority="11" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/><br />
<w:LsdException Locked="false" Priority="22" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Strong"/><br />
<w:LsdException Locked="false" Priority="20" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/><br />
<w:LsdException Locked="false" Priority="59" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Table Grid"/><br />
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/><br />
<w:LsdException Locked="false" Priority="1" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/><br />
<w:LsdException Locked="false" Priority="60" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Shading"/><br />
<w:LsdException Locked="false" Priority="61" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light List"/><br />
<w:LsdException Locked="false" Priority="62" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Grid"/><br />
<w:LsdException Locked="false" Priority="63" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 1"/><br />
<w:LsdException Locked="false" Priority="64" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 2"/><br />
<w:LsdException Locked="false" Priority="65" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 1"/><br />
<w:LsdException Locked="false" Priority="66" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 2"/><br />
<w:LsdException Locked="false" Priority="67" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 1"/><br />
<w:LsdException Locked="false" Priority="68" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 2"/><br />
<w:LsdException Locked="false" Priority="69" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 3"/><br />
<w:LsdException Locked="false" Priority="70" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Dark List"/><br />
<w:LsdException Locked="false" Priority="71" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Shading"/><br />
<w:LsdException Locked="false" Priority="72" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful List"/><br />
<w:LsdException Locked="false" Priority="73" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Grid"/><br />
<w:LsdException Locked="false" Priority="60" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Shading Accent 1"/><br />
<w:LsdException Locked="false" Priority="61" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light List Accent 1"/><br />
<w:LsdException Locked="false" Priority="62" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Grid Accent 1"/><br />
<w:LsdException Locked="false" Priority="63" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/><br />
<w:LsdException Locked="false" Priority="64" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/><br />
<w:LsdException Locked="false" Priority="65" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/><br />
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/><br />
<w:LsdException Locked="false" Priority="34" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/><br />
<w:LsdException Locked="false" Priority="29" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Quote"/><br />
<w:LsdException Locked="false" Priority="30" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/><br />
<w:LsdException Locked="false" Priority="66" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/><br />
<w:LsdException Locked="false" Priority="67" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/><br />
<w:LsdException Locked="false" Priority="68" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/><br />
<w:LsdException Locked="false" Priority="69" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/><br />
<w:LsdException Locked="false" Priority="70" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Dark List Accent 1"/><br />
<w:LsdException Locked="false" Priority="71" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/><br />
<w:LsdException Locked="false" Priority="72" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful List Accent 1"/><br />
<w:LsdException Locked="false" Priority="73" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/><br />
<w:LsdException Locked="false" Priority="60" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Shading Accent 2"/><br />
<w:LsdException Locked="false" Priority="61" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light List Accent 2"/><br />
<w:LsdException Locked="false" Priority="62" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Grid Accent 2"/><br />
<w:LsdException Locked="false" Priority="63" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/><br />
<w:LsdException Locked="false" Priority="64" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/><br />
<w:LsdException Locked="false" Priority="65" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/><br />
<w:LsdException Locked="false" Priority="66" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/><br />
<w:LsdException Locked="false" Priority="67" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/><br />
<w:LsdException Locked="false" Priority="68" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/><br />
<w:LsdException Locked="false" Priority="69" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/><br />
<w:LsdException Locked="false" Priority="70" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Dark List Accent 2"/><br />
<w:LsdException Locked="false" Priority="71" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/><br />
<w:LsdException Locked="false" Priority="72" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful List Accent 2"/><br />
<w:LsdException Locked="false" Priority="73" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/><br />
<w:LsdException Locked="false" Priority="60" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Shading Accent 3"/><br />
<w:LsdException Locked="false" Priority="61" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light List Accent 3"/><br />
<w:LsdException Locked="false" Priority="62" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Grid Accent 3"/><br />
<w:LsdException Locked="false" Priority="63" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/><br />
<w:LsdException Locked="false" Priority="64" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/><br />
<w:LsdException Locked="false" Priority="65" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/><br />
<w:LsdException Locked="false" Priority="66" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/><br />
<w:LsdException Locked="false" Priority="67" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/><br />
<w:LsdException Locked="false" Priority="68" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/><br />
<w:LsdException Locked="false" Priority="69" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/><br />
<w:LsdException Locked="false" Priority="70" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Dark List Accent 3"/><br />
<w:LsdException Locked="false" Priority="71" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/><br />
<w:LsdException Locked="false" Priority="72" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful List Accent 3"/><br />
<w:LsdException Locked="false" Priority="73" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/><br />
<w:LsdException Locked="false" Priority="60" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Shading Accent 4"/><br />
<w:LsdException Locked="false" Priority="61" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light List Accent 4"/><br />
<w:LsdException Locked="false" Priority="62" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Grid Accent 4"/><br />
<w:LsdException Locked="false" Priority="63" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/><br />
<w:LsdException Locked="false" Priority="64" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/><br />
<w:LsdException Locked="false" Priority="65" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/><br />
<w:LsdException Locked="false" Priority="66" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/><br />
<w:LsdException Locked="false" Priority="67" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/><br />
<w:LsdException Locked="false" Priority="68" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/><br />
<w:LsdException Locked="false" Priority="69" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/><br />
<w:LsdException Locked="false" Priority="70" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Dark List Accent 4"/><br />
<w:LsdException Locked="false" Priority="71" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/><br />
<w:LsdException Locked="false" Priority="72" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful List Accent 4"/><br />
<w:LsdException Locked="false" Priority="73" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/><br />
<w:LsdException Locked="false" Priority="60" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Shading Accent 5"/><br />
<w:LsdException Locked="false" Priority="61" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light List Accent 5"/><br />
<w:LsdException Locked="false" Priority="62" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Grid Accent 5"/><br />
<w:LsdException Locked="false" Priority="63" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/><br />
<w:LsdException Locked="false" Priority="64" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/><br />
<w:LsdException Locked="false" Priority="65" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/><br />
<w:LsdException Locked="false" Priority="66" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/><br />
<w:LsdException Locked="false" Priority="67" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/><br />
<w:LsdException Locked="false" Priority="68" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/><br />
<w:LsdException Locked="false" Priority="69" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/><br />
<w:LsdException Locked="false" Priority="70" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Dark List Accent 5"/><br />
<w:LsdException Locked="false" Priority="71" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/><br />
<w:LsdException Locked="false" Priority="72" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful List Accent 5"/><br />
<w:LsdException Locked="false" Priority="73" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/><br />
<w:LsdException Locked="false" Priority="60" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Shading Accent 6"/><br />
<w:LsdException Locked="false" Priority="61" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light List Accent 6"/><br />
<w:LsdException Locked="false" Priority="62" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Light Grid Accent 6"/><br />
<w:LsdException Locked="false" Priority="63" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/><br />
<w:LsdException Locked="false" Priority="64" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/><br />
<w:LsdException Locked="false" Priority="65" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/><br />
<w:LsdException Locked="false" Priority="66" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/><br />
<w:LsdException Locked="false" Priority="67" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/><br />
<w:LsdException Locked="false" Priority="68" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/><br />
<w:LsdException Locked="false" Priority="69" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/><br />
<w:LsdException Locked="false" Priority="70" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Dark List Accent 6"/><br />
<w:LsdException Locked="false" Priority="71" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/><br />
<w:LsdException Locked="false" Priority="72" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful List Accent 6"/><br />
<w:LsdException Locked="false" Priority="73" SemiHidden="false"<br />
UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/><br />
<w:LsdException Locked="false" Priority="19" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/><br />
<w:LsdException Locked="false" Priority="21" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/><br />
<w:LsdException Locked="false" Priority="31" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/><br />
<w:LsdException Locked="false" Priority="32" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/><br />
<w:LsdException Locked="false" Priority="33" SemiHidden="false"<br />
UnhideWhenUsed="false" QFormat="true" Name="Book Title"/><br />
<w:LsdException Locked="false" Priority="37" Name="Bibliography"/><br />
<w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/><br />
</w:LatentStyles><br />
</xml><![endif]--><!--[if gte mso 10]><br />
<style><br />
/* Style Definitions */<br />
table.MsoNormalTable<br />
{mso-style-name:"Table Normal";<br />
mso-tstyle-rowband-size:0;<br />
mso-tstyle-colband-size:0;<br />
mso-style-noshow:yes;<br />
mso-style-priority:99;<br />
mso-style-parent:"";<br />
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;<br />
mso-para-margin-top:0cm;<br />
mso-para-margin-right:0cm;<br />
mso-para-margin-bottom:8.0pt;<br />
mso-para-margin-left:0cm;<br />
line-height:107%;<br />
mso-pagination:widow-orphan;<br />
font-size:11.0pt;<br />
font-family:"Calibri","sans-serif";<br />
mso-ascii-font-family:Calibri;<br />
mso-ascii-theme-font:minor-latin;<br />
mso-hansi-font-family:Calibri;<br />
mso-hansi-theme-font:minor-latin;<br />
mso-fareast-language:EN-US;}<br />
</style><br />
<![endif]--> <br />
| <br> Git<br />
| <br> CESNET<br />
| <br> two-clause BSD<br />
| <br><br />
|- style="background:LightGray"<br />
| colspan="2" | Certification web site<br> <br />
| <br> <br />
| GRNET<br> <br />
| GPL <br />
| <br><br />
|- style="background:LightGray"<br />
| colspan="2" | e-Grant <br />
| <br> <br />
| ACC Cyfronet AGH<br> <br />
| <br> <br />
| <br><br />
|- style="background:LightGray"<br />
| colspan="2" | Accounting Repository <br />
| SVN <br />
| Rutherford Appleton Laboratory, STFC, UK on behalf of EGI.eu. <br />
| Apache 2 (https://goc.gridops.org/portal/index.php?Page_Type=Static_HTML&amp;Page=Credits) <br />
| <br><br />
|- style="background:LightGray"<br />
| colspan="2" | GGUS <br />
| <br> <br />
| Karlsruhe Institute of Technology, Kaiserstraße 12, 76131 Karlsruhe <br />
| BMC Software Inc. (http://www.bmc.com/legal/copyright-statement-and-terms-of-use) <br />
| <br><br />
|- style="background:LightGray"<br />
| colspan="2" | Repository <br />
| SVN/TRACK<br> <br />
[https://svn.hellasgrid.gr/svn/wp5-egi-inspire.egi.eu/ https://svn.hellasgrid.gr/svn/wp5-egi-inspire.egi.eu/] <br />
<br />
| GRNET + JRU <br />
| Apache 2.0 <br />
| Repository in turn uses several 3<sup>rd</sup> party tools, which are licensed under GPL, BSD and other licenses.<br />
|-<br />
| RT scrips and tools <br />
| [http://bestpractical.com/rt/ RT] <br />
| CVS: Root&nbsp;:pserver:anonymous@vcs.ics.muni.cz:/cvs/meta, Repository (with subdirectories) rt/egi/sa2 <br />
| CESNET <br />
| Apache 2.0 <br />
| Cesnet scrips and tools maintained against RT version 3.8.x<br />
|-<br />
| DocDB extensions <br />
| [http://docdb-v.sourceforge.net/ DocDB] <br />
| CVS: Root&nbsp;:pserver:anonymous@vcs.ics.muni.cz:/cvs/meta, Repository DocDB <br />
| CESNET <br />
| GPL2 <br />
| Released DocDB uploaded as "vendor branch" in CVS, CESNET patches maintained on HEAD<br />
|-<br />
| Perun <br />
| [http://perun.cesnet.cz/ Perun] <br />
| GIT: https://github.com/CESNET/perun <br />
| CESNET <br />
| FreeBSD License <br />
| Software used several components under different licenses, e.g. Apache, GNU, CC.<br />
|- style="background:LightGray"<br />
| colspan="2" | rOCCI-* (core, api, cli, server)<br> <br />
| <br> <br />
| CESNET<br> <br />
| Apache License, Version 2.0<br> <br />
| <br><br />
|- style="background:LightGray"<br />
| colspan="2" | oneacct-export<br> <br />
| <br> <br />
| CESNET <br />
| MIT License<br> <br />
| <br><br />
|- style="background:LightGray"<br />
| colspan="2" | jOCCI-* (core, api)<br> <br />
| <br> <br />
| CESNET <br />
| Apache License, Version 2.0 <br />
| <br><br />
|- style="background:LightGray"<br />
| colspan="2" | Cloud-BDII-provider<br> <br />
| [https://github.com/EGI-FCTF/cloud-bdii-provider https://github.com/EGI-FCTF/cloud-bdii-provider] <br />
| <br />
CSIC<br> <br />
<br />
| ASL 2.0<br> <br />
| although this is a FedCloud wide collaboration (authors are A. López, S. Pinto, B. Parak, E. Fernández, B. Hagemeier)<br />
|- style="background:LightGray"<br />
| colspan="2" | OCCI-OS<br> <br />
| [https://github.com/EGI-FCTF/occi-os https://github.com/EGI-FCTF/occi-os] <br />
| CSIC <br />
| ASL 2.0 <br />
| main authors originally from intel, now maintenance done by CSIC<br><br />
|- style="background:LightGray"<br />
| colspan="2" | OSSSM<br> <br />
| [https://github.com/EGI-FCTF/osssm https://github.com/EGI-FCTF/osssm] <br />
| IN2P3<br> <br />
| GPL2<br> <br />
| <br><br />
|- style="background:LightGray"<br />
| colspan="2" | cASO <br />
| [https://github.com/IFCA/caso/ https://github.com/IFCA/caso/] <br />
| CSIC <br />
| ASL 2.0 <br />
| <br><br />
|- style="background:LightGray"<br />
| colspan="2" | keystone-voms <br />
| [https://github.com/IFCA/keystone-voms https://github.com/IFCA/keystone-voms] <br />
| CSIC <br />
| ASL 2.0 <br />
| <br><br />
|- style="background:LightGray"<br />
| colspan="2" | Glancepush-vmcatcher <br />
| [https://github.com/EGI-FCTF/glancepush-vmcatcher2 https://github.com/EGI-FCTF/glancepush-vmcatcher2] <br />
| BIFI <br />
| MIT <br />
| <br><br />
|- style="background:LightGray"<br />
| colspan="2" | OSGC - OpenSource Geospatial Catalogue <br />
| http://sourceforge.net/projects/osgcat/ <br />
| EGI.eu <br />
| GPLv3 <br />
| <br><br />
|- style="background:LightGray"<br />
| colspan="2" | synnefo connectors <br />
| [https://github.com/grnet/synnefo/ https://github.com/grnet/synnefo/] <br />
| GRNET S.A. <br />
| GPL v3 <br />
| synnefo connectors like occi, cdmi, etc<br />
|- style="background:LightGray"<br />
| colspan="2" | Application Database <br />
| <br> <br />
| IASA<br> <br />
| Apache 2.0<br> <br />
| <br />
=== ===<br />
<br />
*Server side: <br />
**Zend Framework (New BSD License) - http://framework.zend.com/license <br />
**MySQL data back-end (GPL) - http://www.mysql.com/about/legal/licensing/index.html <br />
**PHP (PHP License v3.01, an Open Source license) - http://www.php.net/license/3_01.txt <br />
**Apache (Apache License, Version 2.0) - http://www.apache.org/licenses/LICENSE-2.0<br />
<br />
*Client side: <br />
**Dõjõ Toolkit (Academic free license / New BSD License) - http://www.dojotoolkit.org/reference-guide/quickstart/introduction/licensing.html <br />
**jQuery (MIT/GPL v2 License) - http://jquery.org/license <br />
**AMMAPS Flash map- (Commercial Product -Proprietary license Ammap software single web site license) - http://www.ammap.com/licenses/single_web_site/<br />
<br />
|- style="background:LightGray"<br />
| colspan="2" | Training market place <br />
| <br> <br />
| STFC<br> <br />
| EGEE project license and a small number of Creative Commons license objects (ICEAGE summer school audio, resources). The rest are just reference objects e.g. metadata of a book. <br />
| <br><br />
|}<br />
<br />
<br></div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI_CSIRT:Alerts/Linux-2014-12-17&diff=72909EGI CSIRT:Alerts/Linux-2014-12-172014-12-22T13:07:52Z<p>Kouril: </p>
<hr />
<div> ** WHITE information - Unlimited distribution allowed **<br />
** see https://wiki.egi.eu/wiki/EGI_CSIRT:TLP for distribution restrictions **<br />
<br />
Title: EGI SVG/CSIRT Alert/Advisory 'CRITICAL' risk - Linux kernel vulnerabilities [EGI-ADV-20141217] <br />
<br />
Date: 2014-12-17<br />
Updated: 2014-12-22<br />
<br />
URL: https://wiki.egi.eu/wiki/EGI_CSIRT:Alerts/Linux-2014-12-17 <br />
<br />
<br />
Update Summary<br />
==============<br />
<br />
+ 2014-12-18: Added information about Scientific Linux patches<br />
+ 2014-12-20: Added more details about the vulnerability and fixes<br />
+ 2014-12-22: Corrected information about affected versions<br />
<br />
<br />
Introduction<br />
============<br />
<br />
Redhat has announced a series of vulnerabilities in the linux kernel<br />
which have been fixed. The most severe flaw is marked CVE-2014-9322 and<br />
is believed to provide the possibility to escalate unprivileged users'<br />
rights on the system.<br />
<br />
Fixes have been published for RHEL 5 and 6 and their derivates as well<br />
as other Linux distributions.<br />
<br />
<br />
Details<br />
=======<br />
<br />
arch/x86/kernel/entry_64.S in the Linux kernel before 3.17.5 does not<br />
properly handle faults associated with the Stack Segment (SS) segment<br />
register, which allows local users to gain privileges by triggering an<br />
IRET instruction that leads to access to a GS Base address from the<br />
wrong space. (quoted from NVD).<br />
<br />
<br />
Risk category<br />
=============<br />
<br />
The issue CVE-2014-9322 been assessed as CRITICAL risk by the EGI CSIRT<br />
and EGI SVG Risk Assessment Team.<br />
<br />
<br />
Affected software<br />
=================<br />
<br />
The Linux kernel is affected. The issue was fixed in the 3.17.5 version<br />
of the mainstream distribution. The fixes were also backported to other<br />
versions by distribution vendors.<br />
<br />
In the 2.* Linux kernels of RedHat 5 and derivatives the vulnerability<br />
was fixed by version 2.6.18-400.1.1.el5.<br />
In the 2.* Linux kernels of RedHat 6 and derivatives the vulnerability<br />
was fixed by version 2.6.32-504.3.3.el6.<br />
<br />
<br />
Mitigation<br />
==========<br />
<br />
N/A<br />
<br />
<br />
Component installation information<br />
==================================<br />
<br />
For many distributions, patched kernel packages are available. Refer to<br />
your distro's information channels.<br />
<br />
*NOTE* SITES USING IPoIB (IP over InfiniBand):<br />
The 6.6 kernels seem to have problems with IPoIB (IP over InfiniBand). If that <br />
has not been solved (and there is no indication in the errata of that), just <br />
upgrading to the latest 6.6 kernel will not be possible for sites<br />
using IPoIB.<br />
NSC is currently building a 6.5 kernel with the critical security patch<br />
applied. That should enable us to continue running IPoIB.<br />
<br />
Other sites can contact support@nsc.liu.se if they are<br />
interested in our custom kernel.<br />
<br />
<br />
Recommendations<br />
===============<br />
<br />
Sites should update as soon as possible. <br />
<br />
All running resources MUST be either patched or otherwise have a<br />
work-around in place by 2014-12-24 T21:00+01:00. Sites failing to act and/or <br />
failing to respond to requests from the EGI CSIRT team risk site suspension. <br />
<br />
In effect, all must update before going on leave for Christmas.<br />
<br />
<br />
Credit<br />
======<br />
<br />
EGI SVG and CSIRT alerted by Leif Nixon. <br />
IPoIB issues announced by Kent Engström.<br />
<br />
<br />
References<br />
==========<br />
<br />
+ Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-9322<br />
+ Red Hat EL6: https://rhn.redhat.com/errata/RHSA-2014-1997.html<br />
+ Red Hat EL5: https://rhn.redhat.com/errata/RHSA-2014-2008.html<br />
+ Scientific Linux 5: https://www.scientificlinux.org/sl-errata/slsa-20142008-1/<br />
+ Scientific Linux 6: https://www.scientificlinux.org/sl-errata/slsa-20141997-1/<br />
+ CentOS: http://lists.centos.org/pipermail/centos-announce/2014-December/020838.html<br />
+ Debian: https://security-tracker.debian.org/tracker/CVE-2014-9322<br />
+ Ubuntu: http://people.canonical.com/~ubuntu-security/cve/CVE-2014-9322<br />
+ NIST NVD: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9322<br />
<br />
<br />
Timeline <br />
========<br />
Yyyy-mm-dd<br />
<br />
2014-12-16 Vulnerabilities publicly announced<br />
2014-12-17 SVG alerted to vulnerabilities by Leif Nixon <br />
2014-12-17 CSIRT and SVG assess risk as 'Critical' <br />
2014-12-17 Heads up/Alert sent to sites.</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI_CSIRT:Alerts/Linux-2014-12-17&diff=72882EGI CSIRT:Alerts/Linux-2014-12-172014-12-20T13:48:49Z<p>Kouril: </p>
<hr />
<div> ** WHITE information - Unlimited distribution allowed **<br />
** see https://wiki.egi.eu/wiki/EGI_CSIRT:TLP for distribution restrictions ** <br />
<br />
Title: EGI SVG/CSIRT Alert/Advisory 'CRITICAL' risk - Linux kernel vulnerabilities [EGI-ADV-20141217]<br />
<br />
Date: 2014-12-17<br />
Updated: 2014-12-20<br />
<br />
URL: https://wiki.egi.eu/wiki/EGI_CSIRT:Alerts/Linux-2014-12-17<br />
<br />
<br />
Update Summary<br />
==============<br />
<br />
+ 2014-12-18: Added information about Scientific Linux patches<br />
+ 2014-12-20: Added more details about the vulnerability and fixes<br />
<br />
<br />
Introduction<br />
============<br />
<br />
Redhat has announced a series of vulnerabilities in the linux kernel<br />
which have been fixed. The most severe flaw is marked CVE-2014-9322 and<br />
is believed to provide the possibility to escalate unprivileged users'<br />
rights on the system.<br />
<br />
Fixes have been published for RHEL 5 and 6 and their derivates as well<br />
as other Linux distributions.<br />
<br />
<br />
Details<br />
=======<br />
<br />
arch/x86/kernel/entry_64.S in the Linux kernel before 3.17.5 does not<br />
properly handle faults associated with the Stack Segment (SS) segment<br />
register, which allows local users to gain privileges by triggering an<br />
IRET instruction that leads to access to a GS Base address from the<br />
wrong space. (quoted from NVD).<br />
<br />
Risk category<br />
=============<br />
<br />
The issue CVE-2014-9322 been assessed as CRITICAL risk by the EGI CSIRT<br />
and EGI SVG Risk Assessment Team.<br />
<br />
<br />
Affected software<br />
=================<br />
<br />
All Linux kernels in the 3.X series before 3.17.5 unless patched against<br />
this issue.<br />
<br />
<br />
Mitigation<br />
==========<br />
<br />
N/A<br />
<br />
Component installation information<br />
==================================<br />
<br />
For many distributions, patched kernel packages are available. Refer to<br />
your distro's information channels.<br />
<br />
*NOTE* SITES USING IPoIB (IP over InfiniBand):<br />
The 6.6 kernels seem to have problems with IPoIB (IP over InfiniBand). If that<br />
has not been solved (and there is no indication in the errata of that), just<br />
upgrading to the latest 6.6 kernel will not be possible for sites<br />
using IPoIB.<br />
NSC is currently building a 6.5 kernel with the critical security patch<br />
applied. That should enable us to continue running IPoIB.<br />
<br />
Other sites can contact support@nsc.liu.se if they are<br />
interested in our custom kernel.<br />
<br />
<br />
Recommendations<br />
===============<br />
<br />
Sites should update as soon as possible.<br />
<br />
All running resources MUST be either patched or otherwise have a<br />
work-around in place by 2014-12-24 T21:00+01:00. Sites failing to act and/or<br />
failing to respond to requests from the EGI CSIRT team risk site suspension.<br />
<br />
In effect, all must update before going on leave for Christmas.<br />
<br />
<br />
Credit<br />
======<br />
<br />
EGI SVG and CSIRT alerted by Leif Nixon.<br />
IPoIB issues announced by Kent Engström.<br />
<br />
<br />
References<br />
==========<br />
<br />
+ Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-9322<br />
+ Red Hat EL6: https://rhn.redhat.com/errata/RHSA-2014-1997.html<br />
+ Red Hat EL5: https://rhn.redhat.com/errata/RHSA-2014-2008.html<br />
+ Scientific Linux 5: https://www.scientificlinux.org/sl-errata/slsa-20142008-1/<br />
+ Scientific Linux 6: https://www.scientificlinux.org/sl-errata/slsa-20141997-1/<br />
+ CentOS: http://lists.centos.org/pipermail/centos-announce/2014-December/020838.html<br />
+ Debian: https://security-tracker.debian.org/tracker/CVE-2014-9322<br />
+ Ubuntu: http://people.canonical.com/~ubuntu-security/cve/CVE-2014-9322<br />
+ NIST NVD: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9322<br />
<br />
<br />
Timeline<br />
========<br />
Yyyy-mm-dd<br />
<br />
2014-12-16 Vulnerabilities publicly announced<br />
2014-12-17 SVG alerted to vulnerabilities by Leif Nixon<br />
2014-12-17 CSIRT and SVG assess risk as 'Critical'<br />
2014-12-17 Heads up/Alert sent to sites.</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI_CSIRT:Alerts&diff=72881EGI CSIRT:Alerts2014-12-20T13:44:59Z<p>Kouril: /* EGI Alerts / Advisories */</p>
<hr />
<div><!--{{Egi-csirt-header}}--><br />
{{New-Egi-csirt-header}} <br />
<br />
Security alerts and/or security advisories will be sent to all EGI site security contacts or NGI security officers by EGI CSIRT using either an EGI broadcasting tool or a pre-established mailing list. They will also be listed on this page. They may cover a wide range of software, including — but not limited to — the EGI middleware.<br />
<br />
{| {{egi-table}}<br />
!Date !! Title !! Contents !! Rating<br />
|-<br />
|2010-XX-XX || A brief discription || Link to the alert/advisory ||Critical/High/Moderate/Low Risk<br />
|}<br />
<br />
The risk rating is in line with [https://wiki.egi.eu/wiki/SVG:Issue_Handling_Summary EGI SVG]'s practice. <br />
<br />
== EGI Alerts / Advisories ==<br />
The following alert bulletins describe security vulnerabilities or immediate threats against one or more sites or the EGI infrastructure and include recommendations and mitigation techniques.<br />
<br />
[[EGI_CSIRT:Alerts/AdvisoryTemplate|This template]] should be used when drafting an advisory.<br />
<br />
{| {{egi-table}}<br />
!Date !! Title !! Contents !! Rating<br />
<br />
|-<br />
<br />
| 2014-12-20 || Advisory concerning kernel vulnerability (CVE-2014-9322) || [[EGI_CSIRT:Alerts/Linux-2014-12-17|Alerts/Linux-2014-12-17]] || Critical<br />
<br />
|-<br />
<br />
|2014-10-31 || Multiple sites report attempts to exploit CVE-2014-7236 affecting Twiki <br />
||[[EGI_CSIRT:Alerts/Twiki-2014-10-31|Alerts/Twiki-2014-10-31]] || High<br />
<br />
|-<br />
<br />
|2014-10-28 || xrootd data protection ||[[EGI_CSIRT:Alerts/xrootd-2014-10-28|Alerts/xrootd-2014-10-28]] ||<br />
<br />
|-<br />
<br />
|2014-10-16 || 'POODLE' vulnerability in SSL version 3 ||[[EGI_CSIRT:Alerts/POODLE-2014-10-16|Alerts/POODLE-2014-10-16]] || Medium<br />
<br />
|-<br />
<br />
|2014-10-01 updated 2014-10-30|| Xen MSR vulnerability - potential memory leak across guest VMs ||[[EGI_CSIRT:Alerts/XSA-108-2014-10-01|Alerts/XSA-108-2014-10-01]] || High<br />
<br />
|-<br />
<br />
|2014-09-29 || Update: 'shellshock' vulnerability - arbitrary code execution via crafted environment variables (CVE-2014-6271, CVE-2014-7177)||[[EGI_CSIRT:Alerts/Shellshock-2014-09-29|Alerts/Shellshock-2014-09-29]] || Critical<br />
<br />
|-<br />
<br />
|2014-09-26 || 'shellshock' vulnerability - arbitrary code execution via crafted environment variables||[[EGI_CSIRT:Alerts/Shellshock-2014-09-26|Alerts/Shellshock-2014-09-26]] || Critical<br />
|-<br />
<br />
|-<br />
<br />
|-<br />
<br />
|2014-07-04|| Linux Kernel Privilege escalation vulnerability CVE-2014-3153 <br />
|| [[EGI_CSIRT:Alerts/LinuxKernel-2014-07-04|Alerts/LinuxKernel-2014-07-04 ]] || High<br />
|-<br />
<br />
|-<br />
<br />
|-<br />
<br />
|2014-04-08|| OpenSSL "Heartbleed" Vulnerability (CVE-2014-0160)<br />
|| [[EGI_CSIRT:Alerts/OpenSSL-2014-04-08|Alerts/OpenSSL-2014-04-08 ]] || Critical<br />
|-<br />
<br />
|-<br />
<br />
|2014-04-07|| Vulnerability Announced in Lustre<br />
|| [[EGI_CSIRT:Alerts/Lustre-2014-04-07|Alerts/Lustre-2014-04-07 ]] || High<br />
|-<br />
<br />
|-<br />
<br />
|2013-06-19|| Advisory concerning puppet vulnerability (CVE 2013-3567)<br />
|| [[EGI_CSIRT:Alerts/puppet-2013-06-19|Alerts/puppet-2013-06-19 ]] || Critical<br />
|-<br />
<br />
|-<br />
<br />
|2013-05-14|| Advisory concerning perf_event kernel vulnerability (CVE-2013-2094)<br />
|| [[EGI_CSIRT:Alerts/kernel-2013-05-14|Alerts/kernel-2013-05-14 ]] || Critical<br />
|-<br />
<br />
|2013-03-18|| Advisory concerning ptrace kernel vulnerability (CVE-2013-0871)<br />
|| [[EGI_CSIRT:Alerts/kernel-2013-03-18|Alerts/kernel-2013-03-18 ]] || High<br />
|-<br />
<br />
|2012-08-01|| Advisory concerning gLite 3.2 middleware components no longer supported on 01 August 2012.<br />
|| [[EGI_CSIRT:Advisory/EGI-ADV-20120801/ |Advisory-EGI-ADV-20120801 ]] || Advisory<br />
|-<br />
|2012-07-17|| Critical - Wrong permissions on directory containing user proxies|| [[EGI_CSIRT:Alerts/EMI-1-WMS-file-permissions |Alerts/EMI-1-WMS-file-permissions-2012-07-16]] || Critical<br />
|-<br />
|2012-07-16|| Advisory - EGI CSIRT:Advisory; Upgrade gLite-3*, RHel4* and derivatives || [[EGI_CSIRT:Advisory |Advisory;Upgrade gLite-3*, RHel4* and derivatives]] || Advisory<br />
|-<br />
|2012-02-06|| MODERATE RISK - Multiple Vulnerabilities in the libxml (CVE-2012-3919 etc.)|| [[EGI_CSIRT:Alerts/libxml2-2012-02-06 |Alerts/libxml2-2012-02-06]] || Moderate<br />
|-<br />
|2012-01-23 || High risk vulnerability in Linux kernel: Insufficient /proc/pid/mem access control (CVE-2012-0056) || [[EGI_CSIRT:Alerts/kernel-2012-01-23|Alerts/kernel-2012-01-23]] || High<br />
|-<br />
|2011-12-28 || Critical telnetd vulnerability - Remote root vulnerability in telnet daemons (CVE-2011-4862) || [[EGI_CSIRT:Alerts/telnetd-2011-12-28|Alerts/telnetd-2011-12-28]] || Critical<br />
|-<br />
|2011-06-15 || High Risk - Torque Authentication Bypass Vulnerability (CVE-2011-2907) || [[EGI_CSIRT:Alerts/Torque-2011-06-15|Alerts/Torque-2011-06-15]] || High<br />
|-<br />
|2011-04-12 || HIGH Risk glibc Vulnerability - privilege escalation (CVE-2011-0536) || [[EGI_CSIRT:Alerts/glibc-2011-04-12|Alerts/glibc-2011-04-12]] || High<br />
|-<br />
|2011-03-30 || Critical Vulnerability detected in dCache Admin Web Interface || [[EGI_CSIRT:Alerts/dCache-2011-03-30|Alerts/dCache-2011-03-30]] || Critical<br />
|-<br />
|2011-01-07 || High Risk Kernel Vulnerability:heap overflow in tipc_msg_build() (CVE-2010-3859)|| [[EGI_CSIRT:Alerts/tipc-2011-01-07|Alerts/tipc-2011-01-07]] || High<br />
|-<br />
|2010-12-16 || HIGH root vulnerabilities in Tivoli Storage Manager (TSM) client software || [[EGI_CSIRT:Alerts/tsm-2010-12-16|Alerts/tsm-2010-12-16]] || High<br />
|-<br />
|2010-11-18 || CRITICAL Local root vulnerability in systemtap (CVE-2010-4170) || [[EGI_CSIRT:Alerts/systemtap-2010-11-18|Alerts/systemtap-2010-11-18]] || Critical<br />
|-<br />
|2010-11-02 || HIGH iovec integer overflow in net/rds/rdma.c (CVE-2010-3865) || [[EGI_CSIRT:Alerts/rds-rdma-2010-11-02|Alerts/rds/rdma-2010-11-02]] || High<br />
|-<br />
|2010-10-23 || HIGH Vulnerability in C library dynamic linker (CVE-2010-3856) || [[EGI_CSIRT:Alerts/liblinker-2010-10-23|Alerts/liblinker-2010-10-23]] || High<br />
|-<br />
|2010-10-20 || HIGH Local root vulnerability in RDS (CVE-2010-3904) || [[EGI_CSIRT:Alerts/rds-2010-10-20|Alerts/rds-2010-10-20]] || High<br />
|-<br />
|2010-10-18 || HIGH Vulnerability in C library dynamic linker (CVE-2010-3847) || [[EGI_CSIRT:Alerts/liblinker-2010-10-18|Alerts/liblinker-2010-10-18]] || High<br />
|-<br />
|2010-09-30 || RHEL4 patch for CVE-2010-3081 kernel vulnerability (CVE-2010-3081) || [[EGI_CSIRT:Alerts/kernel-2010-09-30|Alerts/kernel-2010-09-30]] || Moderate<br />
|-<br />
|2010-09-16 || Critical Kernel Vulnerability: 64-bit Compatibility Mode Stack Pointer Corruption (CVE-2010-3081)|| [[EGI_CSIRT:Alerts/kernel-2010-09-16|Alerts/kernel-2010-09-16]] || Critical<br />
|-<br />
|2010-08-18 || Moderate Impact Vulnerabilities in Elog Web Application || [[EGI_CSIRT:Alerts/elog-2010-08-18|Alerts/elog-2010-08-18]] || Moderate<br />
|-<br />
|2010-06-28 || Moderate Impact Vulnerability In Intel Compiler Suite || [[EGI_CSIRT:Alerts/intel-28-06-2010|Alerts/intel-28-06-2010]] || Moderate<br />
|}<br />
<br />
== EGEE Alerts ==<br />
List of alerts published during EGEE <br />
<br />
{| {{egi-table}}<br />
!Date !! Title !! Contents !! Rating<br />
|-<br />
|2009-11-24 || Critical-risk vulnerabilities CVE-2009-3547 || [https://wiki.egi.eu/csirt/index.php/Internal_Notes_on_CVEs Alerts/cve-3547] ||Critical risk<br />
|-<br />
|2009-10-20 || High-risk vulnerabilities in CREAM CE software || [[EGI_CSIRT:Alerts/cream-20-10-2009|Alerts/cream-20-10-2009]] ||High risk<br />
|-<br />
|2009-07-09 || Remote command execution in Nagios WAP/WML interface || [[EGI_CSIRT:Alerts/nagios-09-07-2009|Alerts/nagios-09-07-2009]] ||Medium risk<br />
|-<br />
|2008-07-29 || DNS cache poisoning/spoofing || [[EGI_CSIRT:Alerts/dns-29-07-2008|Alerts/dns-29-07-2008]] ||Medium risk<br />
|-<br />
|2006-10-23 || Critical Vulnerability: OpenPBS/Torque || [[EGI_CSIRT:Alerts/openpbs-23-10-2006|Alerts/openpbs-23-10-2006]] ||Extremely critical<br />
|}<br />
{{From OSCT wiki|http://osct.web.cern.ch/osct/alerts.html}}</div>Kourilhttps://wiki.egi.eu/w/index.php?title=SEC05_Security_Resource_Centre_Certification_Procedure&diff=71417SEC05 Security Resource Centre Certification Procedure2014-11-11T10:24:12Z<p>Kouril: /* Cloud Resource Center */</p>
<hr />
<div>{{New-Egi-csirt-header}} <br />
{{TOC_right}}<br />
<br />
{{Ops_procedures<br />
|Doc_title = Security Resource Centre Certification Procedure<br />
|Doc_link = [https://wiki.egi.eu/wiki/EGI_CSIRT:Security_Resource_Centre_Certification_Procedure|https://wiki.egi.eu/wiki/EGI_CSIRT:Security_Resource_Centre_Certification_Procedure]<br />
|Version = 1.1 - 30 September 2014<br />
|Policy_name = EGI CSIRT<br />
|Contact_group = EGI CSIRT<br />
|Doc_status = Draft<br />
|Procedure_statement = Security Resource Centre Certification Procedure applies to Resource Centres under certification process and re-certification of suspended Resource Centres (sites). This step of the security certification procedure checks that the resources under certification do not contain known CRITICAL software vulnerabilities. <br />
}} <br />
<br />
= Introduction =<br />
<br />
<br>This page provides steps to certify Resource Centre from scurity point of view, as part of [[PROC09|PROC09 Resource Centre Registration and Certification]] procedure. The monitoring is performed using the tools used by the EGI CSIRT and enabled upon request of Resource Centre. <br><br>N.B. The steps below are under development and may change until the process is discussed inside EGI CSIRT and with the EGI operations team. <br><br> <br />
<br />
This step of the security certification procedure checks that the resources under certification do not contain known CRITICAL software vulnerabilities.<br />
<br />
= Steps =<br />
<br />
== HTC Resource Center ==<br />
<br />
{| class="wikitable"<br />
|-<br />
! <br> <br />
! Responsible <br />
! Action <br />
! Prerequisites, if any<br />
|- valign="top"<br />
| 1<br> <br />
| RC<br> <br />
| <br />
'''Ask the EGI CSIRT to enable monitoring of the site.''' <br> <br />
<br />
It is done by opening a ticket in ''"csirt" ''queue of [http://rt.egi.eu EGI RT] or sending a mail to csirt@rt.egi.eu. <br> <br />
<br />
The mail must contain:<br> <br />
<br />
*the name of the Resource Centre<br> <br />
*NGI&nbsp;<br />
<br />
| <br />
|- valign="top"<br />
| 2 <br />
| EGI&nbsp;CSIRT <br />
| <br />
'''Activate the monitoring of the site<br>''' <br />
<br />
After monitoring has been activated the EGI tools will start gathering data and will keep it for evaluation. <br />
<br />
The monitoring has to run for at least 3 consecutive calendar days. <br />
<br />
| <br><br />
|- valign="top"<br />
| 3 <br />
| EGI&nbsp;CSIRT <br />
| If no security alert is raised via the monitoring over 3 consecutive calendar days period, '''the EGI CSIRT will communicate back a positive assesment'''. <br />
| <br />
|}<br />
<br />
== Cloud Resource Center ==<br />
<br />
{| class="wikitable"<br />
|-<br />
! <br> <br />
! Responsible <br />
! Action <br />
! Prerequisites, if any<br />
|- valign="top"<br />
| 1<br> <br />
| RC<br> <br />
| <br />
'''Fill the '''[https://www.surveymonkey.com/s/Cloud_Security_Assessment_for_Resource_Centres '''''EGI&nbsp;security survey''&nbsp;'''] and inform EGI Operations (operations@egi.eu)<br> <br />
<br />
*The purpose of the survey is to assess that the technology used to provide cloud services fulfils the EGI security policies and procedures.<br />
<br />
| <br />
|- valign="top"<br />
| 2 <br />
| EGI Operations <br />
| <br />
'''Send filled in survey to EGI CSIRT''' <br />
<br />
| <br><br />
|- valign="top"<br />
| 3<br> <br />
| EGI&nbsp;CSIRT<br> <br />
| <br />
'''Communicate back an assesment''' '''result'''. <br />
<br />
In case of issues EGI CSIRT&nbsp;contact RC to better understand situation. <br />
<br />
| <br><br />
|}<br />
<br />
= Revision history =<br />
<br />
{| class="wikitable"<br />
|-<br />
! Version <br />
! Authors <br />
! Date <br />
! Comments<br />
|-<br />
| <br />
| <br />
| <br />
| <br />
|}</div>Kourilhttps://wiki.egi.eu/w/index.php?title=SEC05_Security_Resource_Centre_Certification_Procedure&diff=71416SEC05 Security Resource Centre Certification Procedure2014-11-11T10:22:51Z<p>Kouril: /* HTC Resource Center */</p>
<hr />
<div>{{New-Egi-csirt-header}} <br />
{{TOC_right}}<br />
<br />
{{Ops_procedures<br />
|Doc_title = Security Resource Centre Certification Procedure<br />
|Doc_link = [https://wiki.egi.eu/wiki/EGI_CSIRT:Security_Resource_Centre_Certification_Procedure|https://wiki.egi.eu/wiki/EGI_CSIRT:Security_Resource_Centre_Certification_Procedure]<br />
|Version = 1.1 - 30 September 2014<br />
|Policy_name = EGI CSIRT<br />
|Contact_group = EGI CSIRT<br />
|Doc_status = Draft<br />
|Procedure_statement = Security Resource Centre Certification Procedure applies to Resource Centres under certification process and re-certification of suspended Resource Centres (sites). This step of the security certification procedure checks that the resources under certification do not contain known CRITICAL software vulnerabilities. <br />
}} <br />
<br />
= Introduction =<br />
<br />
<br>This page provides steps to certify Resource Centre from scurity point of view, as part of [[PROC09|PROC09 Resource Centre Registration and Certification]] procedure. The monitoring is performed using the tools used by the EGI CSIRT and enabled upon request of Resource Centre. <br><br>N.B. The steps below are under development and may change until the process is discussed inside EGI CSIRT and with the EGI operations team. <br><br> <br />
<br />
This step of the security certification procedure checks that the resources under certification do not contain known CRITICAL software vulnerabilities.<br />
<br />
= Steps =<br />
<br />
== HTC Resource Center ==<br />
<br />
{| class="wikitable"<br />
|-<br />
! <br> <br />
! Responsible <br />
! Action <br />
! Prerequisites, if any<br />
|- valign="top"<br />
| 1<br> <br />
| RC<br> <br />
| <br />
'''Ask the EGI CSIRT to enable monitoring of the site.''' <br> <br />
<br />
It is done by opening a ticket in ''"csirt" ''queue of [http://rt.egi.eu EGI RT] or sending a mail to csirt@rt.egi.eu. <br> <br />
<br />
The mail must contain:<br> <br />
<br />
*the name of the Resource Centre<br> <br />
*NGI&nbsp;<br />
<br />
| <br />
|- valign="top"<br />
| 2 <br />
| EGI&nbsp;CSIRT <br />
| <br />
'''Activate the monitoring of the site<br>''' <br />
<br />
After monitoring has been activated the EGI tools will start gathering data and will keep it for evaluation. <br />
<br />
The monitoring has to run for at least 3 consecutive calendar days. <br />
<br />
| <br><br />
|- valign="top"<br />
| 3 <br />
| EGI&nbsp;CSIRT <br />
| If no security alert is raised via the monitoring over 3 consecutive calendar days period, '''the EGI CSIRT will communicate back a positive assesment'''. <br />
| <br />
|}<br />
<br />
== Cloud Resource Center ==<br />
<br />
{| class="wikitable"<br />
|-<br />
! <br> <br />
! Responsible <br />
! Action <br />
! Prerequisites, if any<br />
|- valign="top"<br />
| 1<br> <br />
| RC<br> <br />
| <br />
'''Fill the '''[https://www.surveymonkey.com/s/Cloud_Security_Assessment_for_Resource_Centres '''''EGI&nbsp;security survey''&nbsp;'''] and inform EGI Operations (operations@egi.eu)<br> <br />
<br />
*The purpose of the survey is to assess that the technology used to provide cloud services fulfils the EGI security policies and procedures.<br />
<br />
| <br />
|- valign="top"<br />
| 2 <br />
| EGI Operations <br />
| <br />
'''Send filled in surver to EGI CSIRT''' <br />
<br />
| <br><br />
|- valign="top"<br />
| 3<br> <br />
| EGI&nbsp;CSIRT<br> <br />
| <br />
'''Communicate back an assesment''' '''result'''. <br />
<br />
In case of issues EGI CSIRT&nbsp;contact RC to better understand situation. <br />
<br />
| <br><br />
|}<br />
= Revision history =<br />
<br />
{| class="wikitable"<br />
|-<br />
! Version <br />
! Authors <br />
! Date <br />
! Comments<br />
|-<br />
| <br />
| <br />
| <br />
| <br />
|}</div>Kourilhttps://wiki.egi.eu/w/index.php?title=SEC05_Security_Resource_Centre_Certification_Procedure&diff=70269SEC05 Security Resource Centre Certification Procedure2014-09-30T10:14:36Z<p>Kouril: </p>
<hr />
<div>{{New-Egi-csirt-header}}<br />
<br />
{{Ops_procedures<br />
|Doc_title = Security Requirements for Resource Centre Registration and Certification<br />
|Doc_link = [https://wiki.egi.eu/w/index.php?title=EGI_CSIRT:Security_Certification]<br />
|Version = 1.1 - 30 September 2014<br />
|Policy_name = EGI CSIRT<br />
|Contact_group = TBA<br />
|Procedure_statement = Operational security requirements to certify new Resource Centres (sites) in the EGI infrastructure. The steps also apply to re-certification of suspended Resource Centres (sites).<br />
}}<br />
<br />
= Overview =<br />
<br />
This page provides instructions on how to enable security monitoring of a grid Resource Centre that is being certified for EGI as requested by the [[PROC09 Resource Centre Registration and Certification]] procedure. The monitorinfg is performed using the tools used by the EGI CSIRT and enabled upon request of Resource Centre.<br />
<br />
N.B. The steps below are under development and may change until the process is discussed inside EGI CSIRT and with the EGI operations team. Also the process only applies to certification of grid Resource Centres and does not address certification of cloud providers.<br />
<br />
= Steps =<br />
<br />
# A Resource Centre administrator asks the EGI CSIRT to enable monitoring of the site. It is done by opening a ticket in csirt queue of EGI RT or sending a mail to csirt@rt.egi.eu. The mail must contain the name of the Resource Centre and NGI and . The Centre must be configured to accept jobs from the ops VO ('''TBC''').<br />
<br />
# EGI CSIRT will activate the monitoring of the site. After monitoring has been activated the EGI tools will start gathering data and will keep it for evaluation.<br />
<br />
# The monitoring has to run for at least 3 consecutive calendar days. If no security alert is raised via the monitoring over that period, the EGI CSIRT will issue a positive assesment of the status upon request of the Operations Centre as per step 8 of the procedure ('''TBC''').</div>Kourilhttps://wiki.egi.eu/w/index.php?title=SEC05_Security_Resource_Centre_Certification_Procedure&diff=70268SEC05 Security Resource Centre Certification Procedure2014-09-30T09:22:49Z<p>Kouril: </p>
<hr />
<div>{{New-Egi-csirt-header}}<br />
<br />
{{Ops_procedures<br />
|Doc_title = Security Requirements for Resource Centre Registration and Certification<br />
|Doc_link = [https://wiki.egi.eu/w/index.php?title=EGI_CSIRT:Security_Certification]<br />
|Version = 1.0 - 4 December 2013<br />
|Policy_name = EGI CSIRT<br />
|Contact_group = TBA<br />
|Procedure_statement = Operational security requirements to certify new Resource Centres (sites) in the EGI infrastructure. The steps also apply to re-certification of suspended Resource Centres (sites).<br />
}}<br />
<br />
= Overview =<br />
<br />
This page provides instructions on how to enable security monitoring of a grid Resource Centre that is being certified for EGI as requested by the [[PROC09 Resource Centre Registration and Certification]] procedure. The monitorinfg is performed using the tools used by the EGI CSIRT and enabled upon request of Resource Centre.<br />
<br />
= Steps =<br />
<br />
1.</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI_CSIRT:IRTF&diff=68123EGI CSIRT:IRTF2014-06-13T10:40:34Z<p>Kouril: /* Tasks */</p>
<hr />
<div>{{egi-csirt-team-header|Incident Response Task Force}}<br />
<!--{{New-Egi-csirt-header}}--><br />
== Objective ==<br />
Handle day to day operational security issues and coordinate Computer-Security-Incident-Response across the EGI infrastructure.<br />
== Tasks ==<br />
* Replace [https://twiki.cern.ch/twiki/bin/view/LCG/OSCT OSCT-DC]<br />
* Swift response to any reported computer security incident affecting EGI infrastruture<br />
* Security Incident Management<br />
** Existing communication channel (mail list/security wiki) migration<br />
** New communication channel (if needed) setup<br />
** Incident response tools development, evaluation and adaptation<br />
** Incident handling procedures update/maintainence <br />
* Establish additional operational and/or escalation procedures when required<br />
** a procedure to suspend a site from the EGI infrastructure<br />
** a procedure and agreed criteria to ban (blacklist) a user, a group of users and/or a VO <br />
* vulnerability assessment<br />
** Regularly monitor vulnerability databases<br />
** Assess impact of vulnerabilities on the EGI infrastructure<br />
** Advise the project mitigation solutions<br />
* Maintain and extend open source intelligence and information exchange with trusted partners<br />
** Gather information about current cyber attack and threats<br />
** Derive monitoring rules applicable to EGI<br />
<br />
== Persons ==<br />
=== Coordinator ===<br />
* Leif Nixon from NGI_NDGF<br />
<br />
=== Volunteers ===<br />
{| {{egi-table}} class="sortable"<br />
! Name !! NGI !! Home Organization !! Effort Avalible (PM)<br />
|-<br />
|Leif Nixon ||- || NDGF ||<br />
|- <br />
|Ake Sandgren ||- || NDGF HPC2N ||<br />
|- <br />
|Daniel Kalici (for Malware Analysis) ||- || NDGF ||<br />
|- <br />
|Daniel Kouril ||- || CESNET ||<br />
|- <br />
|Michal Prochazka ||-|| CESNET || <br />
|- <br />
|Dorine Fouossong || France NGI || <br />
|- <br />
|David O'Callaghan || Ireland NGI || TCD <br />
|- <br />
|Mingchao Ma || UK NGI || STFC - RAL <br />
|- <br />
|Christos Triantafyllidis || Greek NGI || <br />
|- <br />
|Ursula Epting || German NGI || KIT-GridKa <br />
|- <br />
|Tobias Dussa || German NGI || KIT-CERT <br />
|- <br />
|Michael Hausding || Switzerland NGI || SWITCH <br />
|- <br />
|Carlos Fuentes || Spanish NGI || RedIris || <br />
|- <br />
|Sven Gabriel || Dutch NGI || NIKHEF ||<br />
|- <br />
|Nuno Dias ||Portugal NGI || LIP || <br />
|-<br />
|Adam Smutnicki || Polish NGI || WCNS ||<br />
|- <br />
|} <br />
<br />
Vulnerability assessment (part of incident response task force)<br />
{| {{egi-table}} class="sortable"<br />
!Name !! NGI !! Home Organization !! Effort Available (PM)<br />
|-<br />
|Leif Nixon ||- || NDGF ||<br />
|-<br />
|Michael Hausding || Switzerland NGI || SWITCH <br />
|-<br />
|Xander Jansen || Dutch NGI || SURFcert <br />
|-<br />
|Detlev Matthies || German NGI || DFN <br />
|-<br />
|Dorine Fouossong || France NGI||<br />
|- <br />
|}</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI_CSIRT:SMG&diff=68122EGI CSIRT:SMG2014-06-13T10:35:37Z<p>Kouril: </p>
<hr />
<div>{{egi-csirt-team-header|Security Monitoring Group}} <br />
<br />
== Long-term Objectives ==<br />
<br />
Security monitoring is a key component to security. The EGI CSIRT works to provide the EGI, NGI and site security staff with tools and procedures to detect and contain security incidents as well as weaknesses that could lead to a compromise. In doing so, the EGI CSIRT collaborates closely with the sites and NGI, however it does not provide replacements for site and NGI level monitoring. Even though the results developed are primarily ment for EGI, they are designed and developed so that they could be utilized on the site and/or NGI level as well. <br />
<br />
The EGI CSIRT strives to collect various information from the infrastructure, even using own probes and sensors or by combining results generated by other systems (e.g., accounting) on different levels of the infrastructure. The data collected will be evaluated based on current needs and risks, and alarms raised accordingly. The security monitoring system will provide both high-level overview to get a quick notion about the infrastructure as well as a sufficient level of details necessary to sort out security issues detected. The system will archive and evaluate history to follow and forecast trends in security. <br />
<br />
Security monitoring will also provide mechanisms and tools to assist inincident containment, for example to gather important log records. Information about users' activities will be used to identify last actions performed by a user to e.g. estimate the sites possibly infected. A way of (semi)automated processing of alerts and warnings issued by the EGI security groups will be investigate and possibly developed. <br />
<br />
In order to accomplish the objectives, the EGI CSIRT will develop own tools, mainly to grid specific areas and use existing tools if possible and advise on their usage. Developed probes are not intrusive and do not attempt tocircumvent any security mehanisms and are not resource intensive. Results collected by these probes are only available to the EGI CSIRT members and communicated to the appropriate site security contacts. We will also provide recommendations and advisories to the sites and NGI as to how to combine existing technologies to provide efficient local security monitoring. When applicable, collaboration will be established with similar groups of NREN CSIRTs. The tools should be seamlessly integrated with common operational mechanisms used routinely by the security and operations. <br />
<br />
== Monitoring probes ==<br />
<br />
The results produced by the security monitoring tools are available from the [https://operations-portal.egi.eu/csiDashboard EGI Security dashboard], which records the outputs of the following probes: <br />
<br />
*CRL checks (eu.egi.sec.WN-CRL-ops) <br />
**Verifies that all CRLs exist and are current <br />
**ERROR: an out-dated or missing CRL detected <br />
**WARNING: an CRL is about to expire<br />
<br />
*Dangerous filesystem permissions (eu.egi.sec.WN-Permissions-ops) <br />
**Detects world-writable files or directories in exported environment. These files can be misused to information leak, tempering with results or even identity thefts. <br />
**ERROR: writable executables or directory with common commands<br />
<br />
*Vulnerable file permissions (eu.egi.sec.WN-FilePermVulns-ops) <br />
**Detects vulnerable file permissions as per CVE-2009-4033 (/var/log/acpid), which could lead to privilege escalations. <br />
**ERROR: Vulnerable file detected<br />
<br />
*Torque vulnerability (eu.egi.sec.WN-Torque-ops) <br />
**Checks whether torque server that the WN is using has vulnerable options turned on, as per [https://wiki.egi.eu/wiki/EGI_CSIRT:Alerts/Torque-2011-06-15 EGI-ADV-20110615-02] <br />
**ERROR: A vulnerable option detected<br />
<br />
*Pakiti client (eu.egi.sec.WN-Pakiti-ops) <br />
**Reports a list of installed packages to the EGI Pakiti servers. The more detailed information about Pakiti results are available from the Dashboard.<br />
**Error: Any critical vulnerability detected<br />
** Warning: Any High-rated vulnerability detected<br />
<br />
*Following probes are reported but will probably be removed (at least temporarily): <br />
**eu.egi.sec.ARCCE-Jobsubmit-ops <br />
**eu.egi.sec.CE-JobState-ops <br />
**eu.egi.sec.CREAMCE-JobSubmit-ops <br />
**eu.egi.sec.CE-JobSubmit-ops <br />
**eu.egi.sec.CREAMCE-JobState-ops<br />
<br />
Any ERROR state are expected to get fixed within two businnes days. Any WARNINGs must be addressed within a month.<br />
<br />
== Tasks ==<br />
<br />
=== Monitoring of security patches using [http://pakiti.sf.net/ Pakiti] ===<br />
<br />
*finer access control, e.g., based on information from GOC DB <br />
*Generating statistics and reports <br />
*Tagging of and notifications (alarms) about severe vulnerabilities <br />
*Producing OVAL format for EGI advisories (e.g. SVG ones) and their processing <br />
*Support NGIs in setting a local instances of Pakiti <br />
*Performance improvements if needed/asked <br />
*Integration with existing monitoring frameworks (Nagios) <br />
*Pakiti server verification <br />
*Integration with dashboards, UI improvements <br />
*Operation of the EGI Pakiti server at CESNET <br />
*Simplification of the installation procedure<br />
<br />
=== Security monitoring with Nagios ===<br />
<br />
*Development of new probes (based on risk analysis and experience with previous incidents) <br />
*Support for short-lived "dynamic" probes (if needed) (a procedure and template for a quick introduction of new "volatile" probes testing some very particular characteristics, which needs a fast reaction <br />
*guides, docs for NGIs/sites <br />
*Support NGIs in setting local instances of CSIRT Nagios <br />
*operation of the CSIRT Nagios instance at GRNET <br />
*Handling of results (raising alarms, sending notifications, access control to results, ...) <br />
*Evaluation of possible integration of security probes with standard Nagios (securing results, ...) <br />
*Integration with dashboards <br />
*Evaluation of results from multiple different sources <br />
*Aggregating security alerts in a single place<br />
<br />
=== Site level tools ===<br />
<br />
*recommendation for setting up a central syslog server <br />
*specification of filters for the syslog <br />
*(semi)automatic processing of EGI security advisories (checking logs for IP addresses, DNs, ...) <br />
*best practises for log maintanence<br />
<br />
=== Security Dashboard ===<br />
<br />
*providing a single place to overwiew current status, history and provide additional details <br />
*integration with existing EGI dashboards and appropriate frameworks will be evaluated<br />
<br />
== Persons ==<br />
<br />
=== Coordinator ===<br />
<br />
*Daniel Kouril (kouril@ics.muni.cz), Czech Republic NGI</div>Kourilhttps://wiki.egi.eu/w/index.php?title=SEC05_Security_Resource_Centre_Certification_Procedure&diff=62614SEC05 Security Resource Centre Certification Procedure2013-12-04T15:59:22Z<p>Kouril: Created page with "{{New-Egi-csirt-header}} {{Ops_procedures |Doc_title = Security Requirements for Resource Centre Registration and Certification |Doc_link = [https://wiki.egi.eu/w/index.php?titl..."</p>
<hr />
<div>{{New-Egi-csirt-header}}<br />
<br />
{{Ops_procedures<br />
|Doc_title = Security Requirements for Resource Centre Registration and Certification<br />
|Doc_link = [https://wiki.egi.eu/w/index.php?title=EGI_CSIRT:Security_Certification]<br />
|Version = 1.0 - 4 December 2013<br />
|Policy_name = EGI CSIRT<br />
|Contact_group = TBA<br />
|Procedure_statement = Operational security requirements to certify new Resource Centres (sites) in the EGI infrastructure. The steps also apply to re-certification of suspended Resource Centres (sites).<br />
}}<br />
<br />
= Overview =<br />
<br />
= Steps =</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI_CSIRT:Main_Page&diff=62613EGI CSIRT:Main Page2013-12-04T15:48:49Z<p>Kouril: </p>
<hr />
<div>{{New-Egi-csirt-header}}<br />
{{TOC_right}}<br />
<br />
== EGI CSIRT Mission ==<br />
<br />
The EGI CSIRT covers all aspects of operational security aimed at achieving a ''secure infrastructure'' within EGI and relies on site and NGI security contact information maintained in the GOCDB by each NGI. The EGI CSIRT ensures both the coordination with peer grids and with the NGIs and NREN CSIRTs. The EGI CSIRT acts as a forum to combine efforts and resources from the NGIs in different areas, including Grid security monitoring, Security training and dissemination, and improvements in responses to incidents (e.g. security drills). Each NGI will appoint an NGI Security Officer in order to provide the NGI CSIRT function. The resulting group of NGI Security Officers collaborate as part of the EGI CSIRT. <br />
<br />
The EGI CSIRT is led and coordinated by the EGI Security Officer, whose role and mission are defined by security policies approved by [[EGI]] and the [[NGI]]s. <br />
<br />
EGI CSIRT [https://documents.egi.eu/document/385 Term of Reference (ToR)] <br />
<br />
== <span style="color:#ff0000"> '''How To Report a Security Incident''' </span> ==<br />
<br />
'''<u>This is the official and approved EGI-CSIRT procedure to be followed in case of a security incident</u>''' <br />
<br />
*'''[https://wiki.egi.eu/wiki/EGI_CSIRT:Incident_reporting Incident Response Procedure]''' <!--<br />
== Contacts ==<br />
<br />
*EGI Security Officer&nbsp;: Sven Gabriel [[User:sveng|Sven Gabriel]]<br />
*Use the email address '''abuse (at) egi.eu ''' to report security incident and/or abuse [https://wiki.egi.eu/wiki/EGI_CSIRT:Incident_reporting] <br />
*[[EGI CSIRT:Contacts|Others contacts informations]] <br />
*EGI CSIRT is [https://www.trusted-introducer.org/teams/egi-csirt.html listed Trusted Introducer]<br />
--><br />
<br />
== EGI CSIRT Operation Policies and Procedures ==<br />
Operational [[EGI CSIRT:Policies|Procedures]] approved by the OMB and PMB of interest for sites and users.<br />
<br />
ALL EGI sites are required to follow these procedures in order to report and handle Grid-related security incident. We strongly encourage all the security contacts and system administrators to have a printed copy of all of them.<br />
<br />
EGI CSIRT is involved in the ''[https://wiki.egi.eu/wiki/PROC09 Resource Centre Registration and Certification]'' process. To pass the #7 step of the process the site must fulfill the EGI [[EGI CSIRT:Security Certification|security certification]] requirements.<br />
<br />
== EGI CSIRT Security Alerts ==<br />
Security alerts and/or security advisories will be sent to all EGI site security contacts or NGI security officers by EGI CSIRT using either an EGI broadcasting tool or a pre-established mailing list. They will also be listed on [https://wiki.egi.eu/wiki/EGI_CSIRT:Alerts this page]. They may cover a wide range of software, including '''but not limited to''' the EGI middleware.<br />
<br />
== EGI CSIRT Members ==<br />
You can find contact information of the team members [https://wiki.egi.eu/wiki/EGI_CSIRT:Members here]<br />
<br />
== RFC-2350 ==<br />
[https://wiki.egi.eu/wiki/EGI_CSIRT:RFC_2350 RFC-2350 Document] and [https://www.trusted-introducer.org/teams/egi-csirt.html Trusted Introducer entry]<br />
<br />
== Central-emergency-suspension-project ==<br />
https://wiki.egi.eu/wiki/EGI_CSIRT:central_emergency_suspension_project</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI_CSIRT:Alerts&diff=57937EGI CSIRT:Alerts2013-07-15T16:54:48Z<p>Kouril: /* EGI Alerts / Advisories */</p>
<hr />
<div><!--{{Egi-csirt-header}}--><br />
{{New-Egi-csirt-header}} <br />
<br />
Security alerts and/or security advisories will be sent to all EGI site security contacts or NGI security officers by EGI CSIRT using either an EGI broadcasting tool or a pre-established mailing list. They will also be listed on this page. They may cover a wide range of software, including — but not limited to — the EGI middleware.<br />
<br />
{| {{egi-table}}<br />
!Date !! Title !! Contents !! Rating<br />
|-<br />
|2010-XX-XX || A brief discription || Link to the alert/advisory ||Critical/High/Moderate/Low Risk<br />
|}<br />
<br />
The risk rating is in line with [https://wiki.egi.eu/wiki/SVG:Issue_Handling_Summary EGI SVG]'s practice. <br />
<br />
== EGI Alerts / Advisories ==<br />
The following alert bulletins describe security vulnerabilities or immediate threats against one or more sites or the EGI infrastructure and include recommendations and mitigation techniques.<br />
<br />
[[EGI_CSIRT:Alerts/AdvisoryTemplate|This template]] should be used when drafting an advisory.<br />
<br />
{| {{egi-table}}<br />
!Date !! Title !! Contents !! Rating<br />
<br />
|-<br />
<br />
|2013-06-19|| Advisory concerning puppet vulnerability (CVE 2013-3567)<br />
|| [[EGI_CSIRT:Alerts/puppet-2013-06-19|Alerts/puppet-2013-06-19 ]] || Critical<br />
|-<br />
<br />
|-<br />
<br />
|2013-05-14|| Advisory concerning perf_event kernel vulnerability (CVE-2013-2094)<br />
|| [[EGI_CSIRT:Alerts/kernel-2013-05-14|Alerts/kernel-2013-05-14 ]] || Critical<br />
|-<br />
<br />
|2013-03-18|| Advisory concerning ptrace kernel vulnerability (CVE-2013-0871)<br />
|| [[EGI_CSIRT:Alerts/kernel-2013-03-18|Alerts/kernel-2013-03-18 ]] || High<br />
|-<br />
<br />
|2012-08-01|| Advisory concerning gLite 3.2 middleware components no longer supported on 01 August 2012.<br />
|| [[EGI_CSIRT:Advisory/EGI-ADV-20120801/ |Advisory-EGI-ADV-20120801 ]] || Advisory<br />
|-<br />
|2012-07-17|| Critical - Wrong permissions on directory containing user proxies|| [[EGI_CSIRT:Alerts/EMI-1-WMS-file-permissions |Alerts/EMI-1-WMS-file-permissions-2012-07-16]] || Critical<br />
|-<br />
|2012-07-16|| Advisory - EGI CSIRT:Advisory; Upgrade gLite-3*, RHel4* and derivatives || [[EGI_CSIRT:Advisory |Advisory;Upgrade gLite-3*, RHel4* and derivatives]] || Advisory<br />
|-<br />
|2012-02-06|| MODERATE RISK - Multiple Vulnerabilities in the libxml (CVE-2012-3919 etc.)|| [[EGI_CSIRT:Alerts/libxml2-2012-02-06 |Alerts/libxml2-2012-02-06]] || Moderate<br />
|-<br />
|2012-01-23 || High risk vulnerability in Linux kernel: Insufficient /proc/pid/mem access control (CVE-2012-0056) || [[EGI_CSIRT:Alerts/kernel-2012-01-23|Alerts/kernel-2012-01-23]] || High<br />
|-<br />
|2011-12-28 || Critical telnetd vulnerability - Remote root vulnerability in telnet daemons (CVE-2011-4862) || [[EGI_CSIRT:Alerts/telnetd-2011-12-28|Alerts/telnetd-2011-12-28]] || Critical<br />
|-<br />
|2011-06-15 || High Risk - Torque Authentication Bypass Vulnerability (CVE-2011-2907) || [[EGI_CSIRT:Alerts/Torque-2011-06-15|Alerts/Torque-2011-06-15]] || High<br />
|-<br />
|2011-04-12 || HIGH Risk glibc Vulnerability - privilege escalation (CVE-2011-0536) || [[EGI_CSIRT:Alerts/glibc-2011-04-12|Alerts/glibc-2011-04-12]] || High<br />
|-<br />
|2011-03-30 || Critical Vulnerability detected in dCache Admin Web Interface || [[EGI_CSIRT:Alerts/dCache-2011-03-30|Alerts/dCache-2011-03-30]] || Critical<br />
|-<br />
|2011-01-07 || High Risk Kernel Vulnerability:heap overflow in tipc_msg_build() (CVE-2010-3859)|| [[EGI_CSIRT:Alerts/tipc-2011-01-07|Alerts/tipc-2011-01-07]] || High<br />
|-<br />
|2010-12-16 || HIGH root vulnerabilities in Tivoli Storage Manager (TSM) client software || [[EGI_CSIRT:Alerts/tsm-2010-12-16|Alerts/tsm-2010-12-16]] || High<br />
|-<br />
|2010-11-18 || CRITICAL Local root vulnerability in systemtap (CVE-2010-4170) || [[EGI_CSIRT:Alerts/systemtap-2010-11-18|Alerts/systemtap-2010-11-18]] || Critical<br />
|-<br />
|2010-11-02 || HIGH iovec integer overflow in net/rds/rdma.c (CVE-2010-3865) || [[EGI_CSIRT:Alerts/rds-rdma-2010-11-02|Alerts/rds/rdma-2010-11-02]] || High<br />
|-<br />
|2010-10-23 || HIGH Vulnerability in C library dynamic linker (CVE-2010-3856) || [[EGI_CSIRT:Alerts/liblinker-2010-10-23|Alerts/liblinker-2010-10-23]] || High<br />
|-<br />
|2010-10-20 || HIGH Local root vulnerability in RDS (CVE-2010-3904) || [[EGI_CSIRT:Alerts/rds-2010-10-20|Alerts/rds-2010-10-20]] || High<br />
|-<br />
|2010-10-18 || HIGH Vulnerability in C library dynamic linker (CVE-2010-3847) || [[EGI_CSIRT:Alerts/liblinker-2010-10-18|Alerts/liblinker-2010-10-18]] || High<br />
|-<br />
|2010-09-30 || RHEL4 patch for CVE-2010-3081 kernel vulnerability (CVE-2010-3081) || [[EGI_CSIRT:Alerts/kernel-2010-09-30|Alerts/kernel-2010-09-30]] || Moderate<br />
|-<br />
|2010-09-16 || Critical Kernel Vulnerability: 64-bit Compatibility Mode Stack Pointer Corruption (CVE-2010-3081)|| [[EGI_CSIRT:Alerts/kernel-2010-09-16|Alerts/kernel-2010-09-16]] || Critical<br />
|-<br />
|2010-08-18 || Moderate Impact Vulnerabilities in Elog Web Application || [[EGI_CSIRT:Alerts/elog-2010-08-18|Alerts/elog-2010-08-18]] || Moderate<br />
|-<br />
|2010-06-28 || Moderate Impact Vulnerability In Intel Compiler Suite || [[EGI_CSIRT:Alerts/intel-28-06-2010|Alerts/intel-28-06-2010]] || Moderate<br />
|}<br />
<br />
== EGEE Alerts ==<br />
List of alerts published during EGEE <br />
<br />
{| {{egi-table}}<br />
!Date !! Title !! Contents !! Rating<br />
|-<br />
|2009-11-24 || Critical-risk vulnerabilities CVE-2009-3547 || [https://wiki.egi.eu/csirt/index.php/Internal_Notes_on_CVEs Alerts/cve-3547] ||Critical risk<br />
|-<br />
|2009-10-20 || High-risk vulnerabilities in CREAM CE software || [[EGI_CSIRT:Alerts/cream-20-10-2009|Alerts/cream-20-10-2009]] ||High risk<br />
|-<br />
|2009-07-09 || Remote command execution in Nagios WAP/WML interface || [[EGI_CSIRT:Alerts/nagios-09-07-2009|Alerts/nagios-09-07-2009]] ||Medium risk<br />
|-<br />
|2008-07-29 || DNS cache poisoning/spoofing || [[EGI_CSIRT:Alerts/dns-29-07-2008|Alerts/dns-29-07-2008]] ||Medium risk<br />
|-<br />
|2006-10-23 || Critical Vulnerability: OpenPBS/Torque || [[EGI_CSIRT:Alerts/openpbs-23-10-2006|Alerts/openpbs-23-10-2006]] ||Extremely critical<br />
|}<br />
{{From OSCT wiki|http://osct.web.cern.ch/osct/alerts.html}}</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI_Core_activities:2013-bidding_Security_monitoring_and_security_operations_support_tools&diff=57528EGI Core activities:2013-bidding Security monitoring and security operations support tools2013-07-04T09:59:24Z<p>Kouril: </p>
<hr />
<div>{{TOC_right}}<br />
'''Go back to the [[Core_EGI_Activities|activity list]].'''<br />
* Service name: Security monitoring and security operations support tools<br />
* Service category: Operations<br />
* Service type: Coordination, operation and maintenance<br />
<br />
Security monitoring and security operations support tools are part of the EGI Core Infrastructure Platform which supports the daily security operations of EGI.<br />
<br />
= Introduction =<br />
EGI is an interconnected federation where a single vulnerable place may have a huge impact on the whole infrastructure. In order to recognise the risks and to address potential vulnerabilities in a timely manner, the EGI Security Monitoring provides an oversight of the infrastructure from the security standpoint. Also, sites connected to EGI differ significantly in the level of security and detecting weaknesses exposed by the sites allows the EGI security operations to contact the sites before the issue leads to an incident. Information produced by security monitoring is also important during assessment of new risks and vulnerabilities since it enables to identify the scope and impact of a potential security incident. <br />
<br />
= Technical description =<br />
This service includes the following components.<br />
<br />
== Security Nagios ==<br />
A Security Nagios service is provided to monitor a range of like CRLs, file system permissions, vulnerable file permissions etc. Ad-hoc probes need to be deployed to support incident management, to assess the vulnerability of the infrastructure with regards to specific security issues and for proactive security management. The results produced are available to the EGI Security dashboard for visualization.<br />
<br />
== Pakiti ==<br />
Pakiti is monitoring and notification service which is responsible for checking the patching status of systems. The results produced are available to the EGI Security dashboard for visualization.<br />
<br />
== Incident Reporting Tool ==<br />
RTIR for tracking of incident reporting activities.<br />
<br />
== Tools for Security Service Challenge support ==<br />
Security challenges are a mechanism to check the compliance of sites/NGIs/EGI with security procedures etc. Runs of Security Service Challenges need a set of tools that are used during various stages of the runs. The tools include a web portal used by the SSC operators to control the run, an extension of RTIR for evaluations of sites, and customized Pakiti used in SSC preparation phases.<br />
<br />
== Coordination ==<br />
This activity is responsible of the coordination of the system operation and upgrade activities with those partners that are in charge of operating other systems that depend on it.<br />
Coordination is needed with other security-related tasks, namely the Incident Response Task Force and Software Vulnerability Group. Reliable and quick support to them is needed (for instance to introduce new checks or process collected data). <br />
<br />
== Support ==<br />
* Support to the users of the security monitoring tools, and to NGIs in operating a local instance of Pakiti<br />
* to the operators of other depending systems<br />
* Development and maintenance of guides and documentation for NGIs/sites about security monitoring with Nagios<br />
<br />
'''Support hours''': eight hours a day (for example 9-17 CE(S)T), Monday to Friday – excluding public holidays of the hosting organization.<br />
<br />
== Operation ==<br />
* Daily running of the systems<br />
* Provisioning of a high availability configuration<br />
* A test infrastructure to verify interoperability and the impact of software upgrades on depending systems<br />
<br />
== Maintenance ==<br />
This activity includes:<br />
* development of new probes (based on risk analysis and experience with previous incidents) <br />
* integration of security probes with standard Nagios<br />
* proactive maintenance, improvement of the system<br />
* requirements gathering<br />
* Documentation<br />
<br />
= Service level targets =<br />
*Minimum availability/reliability: 99%/99%<br />
*Response to incident records in GGUS within support hours: [[FAQ_GGUS-PT-QoS-Levels#Medium_service| Medium]] (see https://wiki.egi.eu/wiki/FAQ_GGUS-PT-QoS-Levels#Medium_service)</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI_Core_activities:2013-bidding_Security_monitoring_and_security_operations_support_tools&diff=57526EGI Core activities:2013-bidding Security monitoring and security operations support tools2013-07-04T09:54:05Z<p>Kouril: </p>
<hr />
<div>{{TOC_right}}<br />
'''Go back to the [[Core_EGI_Activities|activity list]].'''<br />
* Service name: Security monitoring and security operations support tools<br />
* Service category: Operations<br />
* Service type: Coordination, operation and maintenance<br />
<br />
Security monitoring and security operations support tools are part of the EGI Core Infrastructure Platform which supports the daily security operations of EGI.<br />
<br />
= Introduction =<br />
EGI is an interconnected federation where a single vulnerable place may have a huge impact on the whole infrastructure. In order to recognise the risks and to address potential vulnerabilities in a timely manner, the EGI Security Monitoring provides an oversight of the infrastructure from the security standpoint. Also, sites connected to EGI differ significantly in the level of security and detecting weaknesses exposed by the sites allows the EGI security operations to contact the sites before the issue leads to an incident. Information produced by security monitoring is also important during assessment of new risks and vulnerabilities since it enables to identify the scope and impact of a potential security incident. <br />
<br />
= Technical description =<br />
This service includes the following components.<br />
<br />
== Security Nagios ==<br />
A Security Nagios service is provided to monitor a range of like CRLs, file system permissions, vulnerable file permissions etc. Ad-hoc probes need to be deployed to support incident management, to assess the vulnerability of the infrastructure with regards to specific security issues and for proactive security management. The results produced are available to the EGI Security dashboard for visualization.<br />
<br />
== Pakiti ==<br />
Pakiti is monitoring and notification service which is responsible for checking the patching status of systems. The results produced are available to the EGI Security dashboard for visualization.<br />
<br />
== Incident Reporting Tool ==<br />
RTIR for tracking of incident reporting activities.<br />
<br />
== Tools for Security Service Challenge support ==<br />
Security challenges are a mechanism to check the compliance of sites/NGIs/EGI with security procedures etc. Runs of Security Service Challenges need a set of tools that are used during various stages of the runs. The tools include a web portal used by the SSC operators, an extension of RTIR for evaluations of sites, and customized Pakiti used in SSC preparation phases.<br />
<br />
== Coordination ==<br />
This activity is responsible of the coordination of the system operation and upgrade activities with those partners that are in charge of operating other systems that depend on it.<br />
Coordination is needed with other security-related tasks, namely the Incident Response Task Force and Software Vulnerability Group. Reliable and quick support to them is needed (for instance to introduce new checks or process collected data). <br />
<br />
== Support ==<br />
* Support to the users of the security monitoring tools, and to NGIs in operating a local instance of Pakiti<br />
* to the operators of other depending systems<br />
* Development and maintenance of guides and documentation for NGIs/sites about security monitoring with Nagios<br />
<br />
'''Support hours''': eight hours a day (for example 9-17 CE(S)T), Monday to Friday – excluding public holidays of the hosting organization.<br />
<br />
== Operation ==<br />
* Daily running of the systems<br />
* Provisioning of a high availability configuration<br />
* A test infrastructure to verify interoperability and the impact of software upgrades on depending systems<br />
<br />
== Maintenance ==<br />
This activity includes:<br />
* development of new probes (based on risk analysis and experience with previous incidents) <br />
* integration of security probes with standard Nagios<br />
* proactive maintenance, improvement of the system<br />
* requirements gathering<br />
* Documentation<br />
<br />
= Service level targets =<br />
*Minimum availability/reliability: 99%/99%<br />
*Response to incident records in GGUS within support hours: [[FAQ_GGUS-PT-QoS-Levels#Medium_service| Medium]] (see https://wiki.egi.eu/wiki/FAQ_GGUS-PT-QoS-Levels#Medium_service)</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI_Core_activities:2013-bidding_Security_monitoring_and_security_operations_support_tools&diff=57514EGI Core activities:2013-bidding Security monitoring and security operations support tools2013-07-04T09:11:03Z<p>Kouril: </p>
<hr />
<div>{{TOC_right}}<br />
'''Go back to the [[Core_EGI_Activities|activity list]].'''<br />
* Service name: Security monitoring and security operations support tools<br />
* Service category: Operations<br />
* Service type: Coordination, operation and maintenance<br />
<br />
Security monitoring and security operations support tools are part of the EGI Core Infrastructure Platform which supports the daily security operations of EGI.<br />
<br />
= Introduction =<br />
EGI is an interconnected federation where a single vulnerable place may have a huge impact on the whole infrastructure. In order to recognise the risks and to address potential vulnerabilities in a timely manner, the EGI Security Monitoring provides an oversight of the infrastructure from the security standpoint. Also, sites connected to EGI differ significantly in the level of security and detecting weaknesses exposed by the sites allows the EGI security operations to contact the sites before the issue leads to an incident. Information produced by security monitoring is also important during assessment of new risks and vulnerabilities since it enables to identify the scope and impact of a potential security incident. <br />
<br />
= Technical description =<br />
This service includes the following components.<br />
<br />
== Security Nagios ==<br />
A Security Nagios service is provided to monitor a range of like CRLs, file system permissions, vulnerable file permissions etc. Ad-hoc probes need to be deployed to support incident management, to assess the vulnerability of the infrastructure with regards to specific security issues and for proactive security management. The results produced are available to the EGI Security dashboard for visualization.<br />
<br />
== Pakiti ==<br />
Pakiti is monitoring and notification service which is responsible for checking the patching status of systems. The results produced are available to the EGI Security dashboard for visualization.<br />
<br />
== Incident Reporting Tool ==<br />
RTIR for tracking of incident reporting activities.<br />
<br />
== Tools for SSC support ==<br />
Security challenges are a mechanism to check the compliance of sites/NGIs/EGI with security procedures etc. Runs of SSCs need a set of tools that are used during various stages of the runs.<br />
<br />
== Coordination ==<br />
This activity is responsible of the coordination of the system operation and upgrade activities with those partners that are in charge of operating other systems that depend on it.<br />
Coordination is needed with other security-related tasks, namely the Incident Response Task Force and Software Vulnerability Group. Reliable and quick support to them is needed (for instance to introduce new checks or process collected data). <br />
<br />
== Support ==<br />
* Support to the users of the security monitoring tools, and to NGIs in operating a local instance of Pakiti<br />
* to the operators of other depending systems<br />
* Development and maintenance of guides and documentation for NGIs/sites about security monitoring with Nagios<br />
<br />
'''Support hours''': eight hours a day (for example 9-17 CE(S)T), Monday to Friday – excluding public holidays of the hosting organization.<br />
<br />
== Operation ==<br />
* Daily running of the systems<br />
* Provisioning of a high availability configuration<br />
* A test infrastructure to verify interoperability and the impact of software upgrades on depending systems<br />
<br />
== Maintenance ==<br />
This activity includes:<br />
* development of new probes (based on risk analysis and experience with previous incidents) <br />
* integration of security probes with standard Nagios<br />
* proactive maintenance, improvement of the system<br />
* requirements gathering<br />
* Documentation<br />
<br />
= Service level targets =<br />
*Minimum availability/reliability: 99%/99%<br />
*Response to incident records in GGUS within support hours: [[FAQ_GGUS-PT-QoS-Levels#Medium_service| Medium]] (see https://wiki.egi.eu/wiki/FAQ_GGUS-PT-QoS-Levels#Medium_service)</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI-InSPIRE:Plan_2013_SA1.2&diff=51955EGI-InSPIRE:Plan 2013 SA1.22013-02-20T21:27:19Z<p>Kouril: /* Milestones not accomplished */</p>
<hr />
<div>{{Template:Op menubar}} {{Template:Inspire_reports_menubar}} {{TOC_right}} <br />
[[Category:EGI-inSPIRE SA1]]<br />
= Assessment of progress in 2012 =<br />
<br />
==Completed Activities and Milestones==<br />
<!-- please make sure that the text here is self explanatory and sufficiently detailed--><br />
<br />
* Q1<br />
** extension of access Monitor Module of SSC5<br />
** 1 NGI run of SSC5 <br />
** further development of security dashboard<br />
** EMI Vulnerability Assessment of VOMS Core completion expected<br />
* Q2 <br />
** Security Threat Risk Assessment (as described in D4.4)<br />
** CSIRT face to face meeting<br />
** extension of SSC5 framework (integration of more job-submission methods), improvement of reporting module<br />
** optimization of alerts in security dashboard<br />
** proposal for site-wide security monitoring<br />
** Update of the EGI Software Vulnerability Group/EMI Vulnerability Assessment plan, including status report. (This is for pro-active examination of software to find vulnerabilities that may exist carried out by our collaborators.)<br />
* Q3<br />
** SSC6<br />
** update of site certification procedure<br />
** SVG face to face meeting<br />
** security training at EGI technical forum<br />
** EMI Vulnerability Assessment of WMS completion started (but delayed by illness)<br />
<br />
* Close collaboration on the MW upgrade campaign<br />
<br />
==Milestones not accomplished==<br />
<!-- list here milestones that were not completed according to the envisaged schedule, saying why they were not completed, and the new schedule is --><br />
<br />
* SVG plans<br />
** WMS, CREAM<br />
** improvement of RTIR ticketing system<br />
** improvement of internal issue handling procedure with RTIR<br />
<br />
** evaluation of SSC6<br />
** nagios: CRL checking on services that have gridftp (CEs/SEs) and checking for known vulnerable file permissions via gridftp<br />
** Revise and improve Vulnerability Issue handing procedure<br />
** EGI CSIRT operational procedure for compromised certificates.<br />
<br />
* Security monitoring<br />
** New version of Pakiti -- largely maintenance performed; no sufficient effort collect to finish current development version<br />
** docs on site-wide monitoring<br />
<br />
= Plans for 2013 =<br />
<!-- add or remove entries below as needed --><br />
<br />
==Cross Security Teams Activities==<br />
<br />
* MS235 Security Activity within EGI Month 34 Report detailing the non-operational security activity within EGI including SCG, SVG, EUGridPMA and IGTF.<br />
* EGI Security Threat risk assessment - Report on what is being done concerning threats of highest risk value and highest impact value.<br />
* Also we should look at Clouds and implications for the various security groups, what needs to be done. Since in the 6th highest risk threat was clouds - and so many seem to assume all the security problems go away and they can ignore us all.<br />
* Also, obviously virtual environments (Cloud as the buzzword) is getting more and more important. Not sure what this means for our monitoring. At the end we might have to follow the natural route:<br />
* have a policy for Cloud/VMs/etc<br />
* depending on this develop monitoring needed to enforce these policies.<br />
<br />
<br />
<br />
==EGI CSIRT Activities==<br />
* we still have to submit the DNs of the IRTF members, this is about to change currently, but might be addressed in Q1<br />
<br />
===CSIRT meetings===<br />
<br />
* Regular monthly team meetings including 2 F2F meetings <br />
<br />
===RTIR ticketing system===<br />
<br />
* <br />
<br />
===Incident Response===<br />
<br />
* Regualar weekly IRTF meetings<br />
* How we deal with loss of active members - build a sustainable future.<br />
<br />
<br />
===Daily security operations===<br />
<br />
* <br />
<br />
===Security drills===<br />
<br />
* The natural agenda would be to run SSC7 in Q2-3, evaluation/debriefing in Q3<br />
* In addition we should try to get the NGI runs done, say one or two in Q1, more in the following Q n<br />
* Here we rely on RT-IR, I hope that Carlos/John can free up some time to migrate this part.<br />
* SSC6 evaluation is depending on that, we need the RT-IR tickets from SSC6 for the report. This is currently not really accessible.<br />
<br />
<br />
<br />
===Security monitoring tools===<br />
<!-- add or remove entries below as needed --><br />
* SHA2 "campaign", if needed continue to support MW-Upgrade campaigns<br />
* site-wide monitoring - a description of plans produced and delivered to OMB (Q1), technical pilot with a few NGIs implemented and evaluated (Q2-Q4)<br />
* Pakiti release - alpha (Q2), final (Q4). If we don't have resources for more extensive development, the current development release will be frozen and stabilized. The EGI instance will be primarily supported focusing mainly on sufficient support for site-wide monitoring.<br />
* probes - overview the SVG/CSIRT issues/alerts and make sure they're monitored, enable sending notifications (Q2).<br />
* Collaboration with dashboard developers<br />
** Involvement of RODs in handling non-criticial issues (our results start appearing in operational dashboard) (Q?)<br />
** Start providing reports to mgmt/NGIs/sites - providing monthly (?) plots summarizing number of issues detected/handled (Q2)<br />
* Monitoring of our tool with EGI-wide monitoring (Q3)<br />
<br />
<br />
====Security Dashboard ====<br />
<br />
* <br />
<br />
====Pakiti====<br />
<br />
* <br />
<br />
====Site wide security monitoring====<br />
<br />
* <br />
<br />
====Nagios security monitoring====<br />
<br />
* <br />
<br />
====Security Training&Dissemination====<br />
<br />
* We have the TF-CSIRT / FIRST in January in Lisbon (Q1)<br />
* I could think of running it again at GKS and TF (Q2/3)<br />
* Additional Trainings might be possible at other Grid-events.<br />
* Wiki renovation<br />
<br />
<br />
====Security procedures====<br />
<br />
* EGI CSIRT operational procedure for compromised certificates. (1st quarter)<br />
<br />
====Other Activities====<br />
<br />
*<br />
<br />
==EGI SVG Activities==<br />
<!-- Add or remove entries as needed --><br />
<br />
===SVG meetings===<br />
<br />
* Regular monthly SVG meetings<br />
* SVG session at Technical Forum<br />
<br />
===Revise and improve Vulnerability Issue handing procedure ===<br />
<br />
* Revise EGI Software Vulnerability Handling procedure for Post EMI/IGE. (Also submitted an abstract to present this at the CF.)<br />
* Poster at CF on how to report a vulnerability or incident (and explain the difference) to be generally useful as well as for the CF. (CSIRT/SVG)<br />
* Further revise Vulnerability issue handling - after a few months using it.<br />
<br />
===Continue Vulnerability issue handling===<br />
<br />
* Regular ongoing work<br />
<br />
===Vulnerability Assessments===<br />
<br />
* Completion of WMS vulnerability Assessment (asked Elisa to confirm)<br />
* Start of CREAM vulnerability Assessment (asked Elisa to confirm)<br />
* Report on Status of Vulnerability assessment after the end of EMI - and whether anything further can be done. <br />
<br />
==Coordination EUGridPMA==</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI-InSPIRE:Plan_2013_SA1.2&diff=51954EGI-InSPIRE:Plan 2013 SA1.22013-02-20T21:26:26Z<p>Kouril: </p>
<hr />
<div>{{Template:Op menubar}} {{Template:Inspire_reports_menubar}} {{TOC_right}} <br />
[[Category:EGI-inSPIRE SA1]]<br />
= Assessment of progress in 2012 =<br />
<br />
==Completed Activities and Milestones==<br />
<!-- please make sure that the text here is self explanatory and sufficiently detailed--><br />
<br />
* Q1<br />
** extension of access Monitor Module of SSC5<br />
** 1 NGI run of SSC5 <br />
** further development of security dashboard<br />
** EMI Vulnerability Assessment of VOMS Core completion expected<br />
* Q2 <br />
** Security Threat Risk Assessment (as described in D4.4)<br />
** CSIRT face to face meeting<br />
** extension of SSC5 framework (integration of more job-submission methods), improvement of reporting module<br />
** optimization of alerts in security dashboard<br />
** proposal for site-wide security monitoring<br />
** Update of the EGI Software Vulnerability Group/EMI Vulnerability Assessment plan, including status report. (This is for pro-active examination of software to find vulnerabilities that may exist carried out by our collaborators.)<br />
* Q3<br />
** SSC6<br />
** update of site certification procedure<br />
** SVG face to face meeting<br />
** security training at EGI technical forum<br />
** EMI Vulnerability Assessment of WMS completion started (but delayed by illness)<br />
<br />
* Close collaboration on the MW upgrade campaign<br />
<br />
==Milestones not accomplished==<br />
<!-- list here milestones that were not completed according to the envisaged schedule, saying why they were not completed, and the new schedule is --><br />
<br />
* SVG plans<br />
** WMS, CREAM<br />
** improvement of RTIR ticketing system<br />
** improvement of internal issue handling procedure with RTIR<br />
<br />
** evaluation of SSC6<br />
** nagios: CRL checking on services that have gridftp (CEs/SEs) and checking for known vulnerable file permissions via gridftp<br />
** Revise and improve Vulnerability Issue handing procedure<br />
** EGI CSIRT operational procedure for compromised certificates.<br />
<br />
* Security monitoring<br />
** New version of Pakiti -- largely maintenance; no sufficient effort collect to finish current development version<br />
** docs on site-wide monitoring<br />
<br />
= Plans for 2013 =<br />
<!-- add or remove entries below as needed --><br />
<br />
==Cross Security Teams Activities==<br />
<br />
* MS235 Security Activity within EGI Month 34 Report detailing the non-operational security activity within EGI including SCG, SVG, EUGridPMA and IGTF.<br />
* EGI Security Threat risk assessment - Report on what is being done concerning threats of highest risk value and highest impact value.<br />
* Also we should look at Clouds and implications for the various security groups, what needs to be done. Since in the 6th highest risk threat was clouds - and so many seem to assume all the security problems go away and they can ignore us all.<br />
* Also, obviously virtual environments (Cloud as the buzzword) is getting more and more important. Not sure what this means for our monitoring. At the end we might have to follow the natural route:<br />
* have a policy for Cloud/VMs/etc<br />
* depending on this develop monitoring needed to enforce these policies.<br />
<br />
<br />
<br />
==EGI CSIRT Activities==<br />
* we still have to submit the DNs of the IRTF members, this is about to change currently, but might be addressed in Q1<br />
<br />
===CSIRT meetings===<br />
<br />
* Regular monthly team meetings including 2 F2F meetings <br />
<br />
===RTIR ticketing system===<br />
<br />
* <br />
<br />
===Incident Response===<br />
<br />
* Regualar weekly IRTF meetings<br />
* How we deal with loss of active members - build a sustainable future.<br />
<br />
<br />
===Daily security operations===<br />
<br />
* <br />
<br />
===Security drills===<br />
<br />
* The natural agenda would be to run SSC7 in Q2-3, evaluation/debriefing in Q3<br />
* In addition we should try to get the NGI runs done, say one or two in Q1, more in the following Q n<br />
* Here we rely on RT-IR, I hope that Carlos/John can free up some time to migrate this part.<br />
* SSC6 evaluation is depending on that, we need the RT-IR tickets from SSC6 for the report. This is currently not really accessible.<br />
<br />
<br />
<br />
===Security monitoring tools===<br />
<!-- add or remove entries below as needed --><br />
* SHA2 "campaign", if needed continue to support MW-Upgrade campaigns<br />
* site-wide monitoring - a description of plans produced and delivered to OMB (Q1), technical pilot with a few NGIs implemented and evaluated (Q2-Q4)<br />
* Pakiti release - alpha (Q2), final (Q4). If we don't have resources for more extensive development, the current development release will be frozen and stabilized. The EGI instance will be primarily supported focusing mainly on sufficient support for site-wide monitoring.<br />
* probes - overview the SVG/CSIRT issues/alerts and make sure they're monitored, enable sending notifications (Q2).<br />
* Collaboration with dashboard developers<br />
** Involvement of RODs in handling non-criticial issues (our results start appearing in operational dashboard) (Q?)<br />
** Start providing reports to mgmt/NGIs/sites - providing monthly (?) plots summarizing number of issues detected/handled (Q2)<br />
* Monitoring of our tool with EGI-wide monitoring (Q3)<br />
<br />
<br />
====Security Dashboard ====<br />
<br />
* <br />
<br />
====Pakiti====<br />
<br />
* <br />
<br />
====Site wide security monitoring====<br />
<br />
* <br />
<br />
====Nagios security monitoring====<br />
<br />
* <br />
<br />
====Security Training&Dissemination====<br />
<br />
* We have the TF-CSIRT / FIRST in January in Lisbon (Q1)<br />
* I could think of running it again at GKS and TF (Q2/3)<br />
* Additional Trainings might be possible at other Grid-events.<br />
* Wiki renovation<br />
<br />
<br />
====Security procedures====<br />
<br />
* EGI CSIRT operational procedure for compromised certificates. (1st quarter)<br />
<br />
====Other Activities====<br />
<br />
*<br />
<br />
==EGI SVG Activities==<br />
<!-- Add or remove entries as needed --><br />
<br />
===SVG meetings===<br />
<br />
* Regular monthly SVG meetings<br />
* SVG session at Technical Forum<br />
<br />
===Revise and improve Vulnerability Issue handing procedure ===<br />
<br />
* Revise EGI Software Vulnerability Handling procedure for Post EMI/IGE. (Also submitted an abstract to present this at the CF.)<br />
* Poster at CF on how to report a vulnerability or incident (and explain the difference) to be generally useful as well as for the CF. (CSIRT/SVG)<br />
* Further revise Vulnerability issue handling - after a few months using it.<br />
<br />
===Continue Vulnerability issue handling===<br />
<br />
* Regular ongoing work<br />
<br />
===Vulnerability Assessments===<br />
<br />
* Completion of WMS vulnerability Assessment (asked Elisa to confirm)<br />
* Start of CREAM vulnerability Assessment (asked Elisa to confirm)<br />
* Report on Status of Vulnerability assessment after the end of EMI - and whether anything further can be done. <br />
<br />
==Coordination EUGridPMA==</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI-InSPIRE:SA1_EGI_Global_tasks_evolution&diff=50339EGI-InSPIRE:SA1 EGI Global tasks evolution2013-01-25T10:49:47Z<p>Kouril: /* Foreseen evolution */</p>
<hr />
<div>[[Category:EGI-inSPIRE SA1]]<br />
This document provided by the partners responsible of EGI operations global tasks provide information about current status and the envisaged evolution of these tasks '''after April 2014'''.<br />
<br />
=Human Services=<br />
==Operation Management Board Coordination==<br />
Partner: EGI.eu<br />
===Current status===<br />
The Operations Management Board (OMB) drives future developments in the operations area by making sure that the infrastructure delivers high availability, is secure, meets the demand of existing user communities and that infrastructure operations evolve to support the integration of new resource infrastructures. It does this by providing management and developing policies and procedures for the operational services that are integrated into the production infrastructure.<br />
The OMB is responsible of technical roadmapping and of the definition and execution of processes for periodic gathering of requirements.<br />
<br />
===Foreseen evolution ===<br />
<br />
====Impact on funding ====<br />
<br />
==Software Support ==<br />
<br />
===Current status===<br />
EGI.eu provides first and second level user and operations support and this function includes the following tasks:<br />
* function coordination (partner: CESNET)<br />
* ticket triage and assignment for dispatching of tickets to the appropriate SUs within GGUS (partners: INFN, CESNET)<br />
* 1st and 2nd level software support, encompassing both grid middleware and operational tools (operational tickets are dispatched to NGI operations SUs, so are not internally addressed by the software support team). This includes the production of howtos and reporting to operations meetings about critical incidents (partners: CESNET, INFN, JUELICH, LIU and STFC<br />
* Ticket oversight and follow-up (partner: KIT): this function includes administrative and reporting functions of the helpdesk infrastructure (e.g. collecting ticket statistics, internal and external reporting of statistics for SLAs monitoring and other reporting duties), and follow-up (notifying supporters when the reaction to high-priority tickets is not fast enough, requesting information from ticket submitters when they do not react, ensuring assigners/resolvers will react sufficiently fast when the submitter provides additional information).<br />
<br />
[https://documents.egi.eu/document/1104| More information about this task]<br />
<br />
===Foreseen evolution ===<br />
<br />
<br />
====Impact on funding ====<br />
<br />
=== Coordination of Grid Oversight ===<br />
Partners: SARA, CYFRONET<br />
<br />
===Current status===<br />
Grid Oversight is an activity aimed at controlling the infrastructure and solving arising operational issues. Theses issues can be of different complexity and importance, and may be caused by various reasons on regional or central level. For the scalability reasons the Grid Oversight has hierarchical structure: teams on regional (ROD) and central (COD) level contribute to it, solving problems within their scope. The COD part of the function is a global task.<br />
Speaking in ITSM terms the processes in which COD is naturally interested in are these of Service<br />
Operations area, especially Incident Management and Problem Management. The oversight of Incident<br />
Management is organized in an escalation process and COD is the body to which incidents that can not<br />
be handled on regional level are escalated.<br />
<br />
===Foreseen evolution ===<br />
After april 2014, there will be more emphasis on supporting NGIs, assistance of user communities with respect to resource allocation. This will be in addition to what is already being done today.<br />
* Read the [https://documents.egi.eu/document/1529 full proposal]<br />
<br />
====Impact on funding ====<br />
This is uncertain.<br />
<br />
== Coordination of network support, monitoring, troubleshooting ==<br />
Partner: GARR<br />
<br />
===Current status===<br />
Provides network support for the resolution of end-to-end network performance issues.<br />
EGI is a highly distributed networked infrastructure of grid services using network connectivity for remote job submission, data transfer and data access, hence tools are needed for network troubleshooting and performance monitoring<br />
<br />
===Foreseen evolution ===<br />
<br />
====Impact on funding ====<br />
<br />
== Coordination of Operational interoperation between NGIs and DCIs ==<br />
Partner: EGI.eu<br />
<br />
===Current status===<br />
EGI coordinates the integration of heterogeneous middleware stacks and Distributed Computing Infrastructures with the EGI operational infrastructures such as: accounting, monitoring, managemenet and support.<br />
<br />
===Foreseen evolution ===<br />
<br />
====Impact on funding ====<br />
<br />
== Coordination of documentation==<br />
Partner: EGI.eu<br />
<br />
===Current status===<br />
Coordination of maintenance and development operational documentation, procedures, best practices.<br />
<br />
===Foreseen evolution ===<br />
====Impact on funding ====<br />
<br />
== Security Operations Coordination ==<br />
Partners: STFC, NIKHEF<br />
<br />
(now including security policy coordination as this is closely related to operations)<br />
<br />
===Current status===<br />
<!-- add and modify text as needed. This paragraph should include: EGI CSIRT, security training, security drills, IRTF, SVG and if you want SPG --><br />
The inherent value of the e-Infrastructure provides a strong rationale for security coordination amongst the EGI participants at various levels. Central coordination of the security activities ensures that policies, operational security, and maintenance are compatible amongst all partners, improving availability and lowering access barriers for use of the infrastructure. Today, the Security Policy Group (SPG) coordinates a consistent set of security policies, developed in collaboration with all interested NGIs, and provides technical implementations of these policies for simplified use by the NGIs where relevant. In addition, security and incident response is provided through the EGI Computer Security and Incident Response Team (CSIRT) by coordinating activity in the NGIs and at the sites across the infrastructure. This coordination ensures that incidents are promptly and efficiently handled, that common policies are followed by providing services such as security monitoring, and by training and dissemination with the goal of improving the response to incidents. The overall incident response capabilities of the sites, also with respect to new technologies introduced by the user communities (VOs), such as the VO-Job-submission frameworks, are frequently assessed through the EGI-wide security drills.<br />
<br />
===Foreseen evolution ===<br />
Security is an ongoing process. Policies, procedures, operations, technology and trust have to constantly evolve to address new threats and risks. In the security threat risk assessment carried out in 2012 one of the threats highlighted as a high risk issue was “The move to more use of Cloud technologies may lead to security problems”. There is no doubt that there will be many issues to be solved in the provision of secure operations as we deploy new technologies, which we are sure will require at least the current level of effort to manage and co-ordinate. We have decided to request the effort we will need for global coordination of security for EGI, based on what we are currently doing and the foreseen future needs. We are convinced that we will continue to need at least this level of effort and that this will need to be funded somehow.<br />
<br />
Experience of providing such security coordination over the last two years has shown that this includes multiple aspects that can be more clearly distinguished when evolving the task for the future, as presented in the following sub-sections.<br />
<br />
====Security Policy Coordination and the support of its implementation====<br />
Security policy development covers diverse aspects, including operational<br />
policies (agreements on vulnerability management, intrusion detection and<br />
prevention, regulation of access, and enforcement), incident response policies<br />
(governing the exchange of information and expected actions), participant<br />
responsibilities (including acceptable use policies, identifying users and<br />
managing user communities), traceability, legal aspects, and the protection<br />
of personal data. In an environment without central control, such as EGI,<br />
common identity management such as provided by the IGTF, is needed to ensure<br />
unique and persistent assignments of rights and privileges. Since research is<br />
global, such policies must be coordinated with peer infrastructures in Europe<br />
and elsewhere, such as PRACE-RI, Open Science Grid, XSEDE, and like efforts in<br />
the Asia Pacific. Coordination mechanisms such as the FIM4R group, TERENA<br />
REFEDS, SCI, Open Grid Forum and the IGTF are employed.<br />
For some elements of these policies (such as the common identity management)<br />
having a central reference implementation for immediate re-use by the NGIs<br />
saves on total effort needed in the long run. The use today of the centrally<br />
produced "EGI trust anchor distribution" is expected to continue.<br />
<br />
====Incident Response Task Force (IRTF) coordination and advanced incident response====<br />
Experience has shown that the complexity of multi-domain incidents at the<br />
scale of EGI necessitates dedicated experts in incident response and forensics<br />
to deal with global incidents and to provide support to EGI participants to<br />
address localised incidents before they spread across EGI. Experience with the<br />
rotational scheme used today in EGI has shown that it is<br />
very hard to retain unique expertise in a widely distributed community with<br />
high personnel turn-over. In practice, incident response is provided by a<br />
dedicated core team, with specialist forensics support concentrated in just a<br />
few individuals. It is essential that this expertise is available as and when<br />
needed, but it cannot provide global coverage for any EGI site. <br />
We propose to establish a small core team which holds the coordination<br />
role and provides advanced support in incident response and forensics.<br />
The primary responsibility for basic incident response and forensics<br />
will still lie with each NGI, while the EGI Global IRTF will coordinate<br />
incident response and information exchange. However, for complex<br />
multi-site incidents and in cases where advanced forensics is needed,<br />
the EGI Global IRTF will step in and take an active part, to protect the<br />
continued integrity of the EGI infrastructure as a whole. Investment in<br />
a relatively small amount of global coordination effort, removes the<br />
need for each NGI to have to maintain its own specialist IT security<br />
capability and has the potential to realise cost savings within each NGI.<br />
<br />
====Software Vulnerability (SVG) coordination====<br />
The Software Vulnerability Group (SVG) aims at eliminating existing vulnerabilities from the deployed infrastructure, primarily from the grid middleware, and avoiding the introduction of new ones, thus preventing security incidents. This activity will need to continue both to handle new vulnerabilities found in the Grid middleware currently deployed, and to handle vulnerabilities in software used by future technology to facilitate the sharing of distributed resources such as federated clouds. The SVG handles vulnerabilities reported in software used specifically in the EGI infrastructure. This depends on investigation and risk assessment by a collaborative team drawn from technology providers and other security groups, known as the Risk Assessment Team or 'RAT'. Considering the recent number of vulnerabilities detected and the co-ordination effort needed with other entities (Technology providers, EGI software distribution managers and coordinators, and central operations co-ordination) this task needs explicit recognition and assignment of dedicated effort. In particular the SVG also has a role in determining the threat posed by software deployed in the infrastructure independent of specific vulnerability events. SVG also has a role in the co-ordination and prioritization of 'Vulnerability Assessment' work, which is the examination of software to find whether any vulnerabilities exist. The SVG has also been asked to assess or advise on the assessment of other pieces of software prior to recommending their deployment on the EGI infrastructure, but has insufficient manpower to carry this out. <br />
<br />
====Security Coordination through Security Service Challenges and Training====<br />
Participating in a global infrastructure is still not a very common task for<br />
some resource centres. Unless specific efforts are made to ensure communication on<br />
incidents is effective between all EGI participants, the 'weakest link'<br />
principle applies and the integrity of the entire infrastructure can<br />
inadvertently be put at risk by a single user or resource. The use of<br />
'security drills', exercising the incident response communications channels,<br />
has proven particularly effective in ensuring open and effective exchange of<br />
information. Additionally, these security drills can be re-used at a site or<br />
national level, where they serve as trainings in computer security forensics<br />
and identification of intrusion and threats.<br />
To be effective, the security drills must be realistic, current with respect<br />
to the software and intrusion vectors used to exercise the site, and be based<br />
on the actual communication infrastructure of EGI. The drills need development<br />
(mainly contributed) and periodic use in realistic tests (the coordination<br />
function included here). Re-using the security drills for training and<br />
national (re)use needs limited 'train the trainer' effort which is best<br />
provided for centrally.<br />
<br />
====Security Monitoring Coordination====<br />
EGI is an interconnected federation where a single vulnerable place may<br />
have a huge impact on the whole infrastructure. In order to recognize<br />
the risks and to address potential vulnerabilities in a timely manner,<br />
the EGI Security Monitoring provides an oversight of the infrastructure<br />
from the security standpoint. Also, sites connected to EGI differ<br />
significantly in the level of security and detecting weaknesses exposed<br />
by the sites allows the EGI security operations to contact the sites<br />
before the issue leads to an incident. Information produced by security<br />
monitoring is also important during assessment of new risks and<br />
vulnerabilities since it enables to identify the scope and impact of a<br />
potential security incident. The whole activity needs to be closely linked to other<br />
security-related tasks, namely the Incident Response Task Force and SVG<br />
and provide reliable and quick support to them (for instance to<br />
introduce new checks or process collected data). The task needs to<br />
cooperate with other activities responsible for general EGI monitoring<br />
and will need to coordinate their developments among these activities. Additional<br />
connections need to be maintained to the operations dashboard and<br />
common activities doing support to sites to make sure detected security issues<br />
are handled properly.<br />
<br />
Development/maintenance of security monitoring is described in the dedicated section on [[#Security Monitoring|security monitoring]].<br />
<br />
===Impact on funding ===<br />
It has already been acknowledged that some areas of security coordination are underfunded today in EGI-InSPIRE. Lack of global effort in the Incident Response Team is a growing problem and the amount of global effort to coordinate SVG (currently 1 PM/year) is way too small. We have therefore decided to give honest estimates of the amount of effort required to perform adequate global coordination of security in EGI. <br />
<br />
Experience over the last 2 years in EGI-InSPIRE has established that the amount of global coordination effort required to perform these critical duties is as follows.<br />
<br />
Person-Months per year, total effort: [partners to be assigned]<br />
<br />
*6+2 PM Security policy coordination and the support of its implementation<br />
*12 PM IRTF coordination and advanced incident response<br />
*6 PM SVG coordination<br />
*6 PM Security coordination through service challenges and training<br />
*4 PM Security monitoring coordination <br />
<br />
Total effort required 36 PM/year.<br />
<br />
== Service Level Management: availability/reliability reports==<br />
Partner: AUTH <br />
=== Current Status ===<br />
This task includes the validation of distribution of monthly availability statistics for Resource Centres, NGIs, EGI.eu, and the coordination of the evolution of the EGI OLA framework and the related reporting tools.<br />
<br />
===Foreseen evolution ===<br />
====Impact on funding ====<br />
<br />
=Infrastructure Services=<br />
<br />
==Software Rollout==<br />
Partner: LIP<br />
<br />
===Current status ===<br />
Updates of deployed software need to be gradually adopted in production after internal verification. This process is implemented in EGI through staged rollout, i.e. through the early deployment of a new component by a selected list of candidate Resource Centres. The successful verification of a new component is a precondition for declaring the software ready for deployment. Given the scale of the EGI infrastructure, this process requires careful coordination to ensure that every new capability is verified by a representative pool of candidate sites, to supervise the responsiveness of the candidate sites and ensure that the staged rollout progresses well without introducing unnecessary delays, and to review the reports produced. It also ensures the planning of resources according to the foreseen release schedules from the Technology Providers. EGI.eu coordination is necessary to ensure a successful interoperation of the various stakeholders: Resource Centres, Technology Providers, the EGI.eu Technical Manager and the EGI repository managers.<br />
<br />
This activities includes:<br />
* Definition and adoption of a workflow to automate software deployment <br />
* Coordination of the staged rollout activities carried out by the NGIs<br />
* Liaison with the UMD team (EGI-InSPIRE SA2)and the Products Teams<br />
<br />
===Foreseen evolution ===<br />
====Impact on funding ====<br />
<br />
== Monitoring ==<br />
=== Central SAM monitoring services===<br />
Partner: CERN <br />
====Current status====<br />
A distributed monitoring framework is necessary to continuously test the level of functionality delivered by each service node instance in the production Resource Centres, to generate alarms and tickets in case of critical failures and to compute monthly availability and reliability statistics, and to monitor and troubleshoot network problems. The Monitoring Infrastructure is a distributed service based on Nagios and messaging. The central services – operated by EGI.eu – include systems such as the MyEGI portal for the visualisation of information, and a set of databases for the persistent storage of information about test results, availability statistics, monitoring profiles and aggregated topology information. The central services need to interact with the local monitoring infrastructures operated by the NGIs. The central monitoring services are critical and need to deliver high availability.<br />
<br />
====Foreseen evolution ====<br />
=====Impact on funding =====<br />
<br />
<br />
=== Broker network=== <br />
Partner: GRNET (coord), SRCE, CERN <br />
====Current status====<br />
====Foreseen evolution ====<br />
=====Impact on funding =====<br />
<br />
<br />
== Accounting ==<br />
<br />
=== APEL central DB ===<br />
Partner: STFC<br />
<br />
====Current status====<br />
The EGI Accounting Infrastructure is distributed. At a central level it includes the repositories for the persistent storage of usage records. The Accounting Infrastructure is essential in a service-oriented business model to record usage information. Accounting data needs to be validated and regularly published centrally. The central databases are populated through individual usage records published by the Resource Centres, or through the publication of summarised usage records.<br />
<br />
===== Dependencies =====<br />
The Accounting Repository has a number of dependencies on other EGI tools:<br />
* Accounting Portal<br />
* GOCDB<br />
* EGI Message Brokers<br />
* GGUS<br />
* Operations Portal and Operations Dashboard<br />
<br />
====Foreseen evolution ====<br />
2013/2014 Technical Evolution: <br />
* Accounting’s evolution over the final year of EGI-InSPIRE will be to consolidate the new Accounting repository to receive records from the EMI APEL 3 client, from the regional APEL server implementations and from other CPU accounting sources (MAPPER, EDGI, UNICORE etc.). Additionally, the archived data in summary form will be migrated to the new format.<br />
* Other types of accounting (Cloud, Storage, Application etc.) is in early testing stage for the accounting repository, although the SSM publishing method has proved robust and usable in these new contexts. Next steps for the coming year are to test with multiple clients ensuring their representation of data is consistent from one client to another and producing summaries for the portal to publish.<br />
<br />
By the end of EGI-Inspire there will be a pervasive accounting infrastructure collecting data for EGI and other International VOs from a number of e-infrastructures including EGI, OSG, NorduGrid, PRACE and a variety of middleware stacks. The central repository will receive data directly from NGI repositories (some running APEL code) from external infrastructures, and directly from sites running various clients, mainly APEL. The infrastructure should handle at least accounting of cpu, storage, and clouds but will be extensible to other types of usage.<br />
<br />
This puts EGI in a good position to exchange accounting data with other infrastructures and to perform a core accounting role.<br />
<br />
* Integration of accounting records from different types of accounting is the next step which would continue after EGI-InSPIRE if funding is available, as this is not yet in development. The implementation of storage accounting integrated with cloud accounting, for example, can only realistically be worked on once we have a body of data from the storage and cloud clients which may be related. Similarly for cloud/cpu and cloud/application integration. The feasibility of this integration requires some research which I envisage could not start until earliest Q3 2013 and would expect it to extend beyond EGI-InSPIRE. <br />
<br />
=====Impact on funding =====<br />
* Costs expected to stay constant up to April 2014 (aiming to address the developments set out in the first two bullets above and continue maintenance and support at the current level). <br />
* Current level of match funding from GridPP is expected until April 2014. <br />
* Reducing costs before April 2014 is unrealistic.<br />
* Post-April 2014 - if there are additional development requirements then funding for these will be required, this would be for further developments in other types of accounting (Cloud, Storage, Application etc.). It is expected that requirements for these would evolve as their usage increases and this will require work beyond maintenance and operations. If the evolution of accounting is to include the integration of data from different types of accounting then this would also require further funding.<br />
<br />
=== Central accounting portal ===<br />
Partner: CESGA<br />
<br />
====Current status====<br />
The EGI accounting infrastructure is a complex system that involves various sensors in different <br />
regions, all publishing data to a central repository. The data is processed, summarized and displayed <br />
in the Accounting Portal, which acts as a common interface to the different accounting record <br />
providers and presents a homogeneous view of the data gathered and a user-friendly access to <br />
understanding resource utilisation.<br />
<br />
The current production version (v4.2 Fomalhaut) of the Accounting Portal is available at https://accounting.egi.eu. The regional Accounting Portal is ready, pending support from APEL regionalization.<br />
<br />
=====Dependencies=====<br />
The Accounting Portal has functional dependencies on the following tools: <br />
<br />
* GOCDB: List of sites and NGIs in production, list of available services in production. <br />
<br />
* CIC Portal: VOMS endpoints and VO list. <br />
<br />
* Accounting Repository: Accounting records and summarized accounting data.<br />
<br />
====Foreseen evolution ====<br />
In the period 2013/2014, the following directions are planned:<br />
* Contributed CPUs by site - Measuring the contribution in CPUs vs the number of hours, enhancing the reporting existing now with SPECInts.<br />
* Preliminar support for parallel (MPI) jobs - There were advances in this after the MPI vt lifespan, but further software development is needed.<br />
* New Accounting: Integration of all advances on Network, Storage and Application accounting on JRA1.4, apart from possible new developments that may arise.<br />
* EGI User usage accounting - Improvements on the userDN accounting.<br />
* Preliminar cloud support - Display and integration of the experimental sites offering cloud computing capabilities under the fedcloud task.<br />
* Regional portal codebase improvements - Implantation and improvement based on regional experiences if appropriate.<br />
* XML endpoints generalization and improvement - Implementation of a friendlier XML interface and documentation for users wishing programmatic access<br />
* Cloud support improvements - Further integration of cloud accounting characteristics.<br />
<br />
=====Impact on funding =====<br />
The funding should remain constant until February 2014. <br />
After February 2014 the status, dedication and funding of staff maintaining the portal is not clear. The availability of National and regional funding is also uncertain, perhaps the situation will be clearer next year.<br />
To ensure continued operation, the funding would have to be maintained at the current level<br />
<br />
== Security Monitoring ==<br />
* Security Nagios server. Partner: GRNET <br />
* CSIRT Pakiti. Partner CESNET <br />
<br />
===Current status ===<br />
The objective of a Security Infrastructure is to protect itself from intrusions such as exploitable software vulnerabilities, misuse by authorised users, resource "theft", etc., while allowing the information, resources and services to remain accessible and productive to its intended users. A specifically designed set of tools and services help reduce these vulnerabilities such as monitoring individual resource centers (based on Nagios and Pakiti), a central security dashboard to allow sites, NGIs and EGI Computer Security Incident Response Teams to access security alerts in a controlled manner, and a ticketing system to support coordination efforts.<br />
<br />
===Foreseen evolution ===<br />
Currently EGI CSIRT runs two services implementing security monitoring, the<br />
security Nagios box and Pakiti service to monitor patch management, which<br />
provide a security-related overview of the infrastructure. Within the scope of <br />
EGI-InSPIRE we plan increase the coverage of EGI (so-call site-wide<br />
monitoring), start producing metrics summarizing level of security as seen by<br />
EGI CSIRT, improve the handling of the issues detected (sending notifications,<br />
close integration with ticketing systems), and finish the next generation of<br />
Pakiti server monitoring security patches. <br />
<br />
====Impact on funding ====<br />
After EGI-InSPIRE we will need to keep at least operations and maintenance of the key services (Pakiti and security Nagios). Estimated costs are 1PM for operations (OPS) and 2PM for maintenance (MAINT) for each service, totaling to 6PM / year for both the services.<br />
<br />
== Configuration Repository (GOCDB) ==<br />
Partner: STFC <br />
===Current status===<br />
EGI relies on a central database (GOCDB) to record static information about different entities such as the Operations Centres, the Resource Centres, and the service instances. It also provides contact, role and status information. GOCDB is a source of information for many other operational tools, such as the broadcast tool, the Aggregated Topology Provider, etc.<br />
<br />
===Foreseen evolution ===<br />
1yr Technical Evolution: <br />
GOCDB needs to evolve along the following themes to address current and emerging stakeholder requirements: <br />
* GOCDB v5 (~April/May). Replaces Oracle PROM database with ORM DB objects. Is needed to support different RDBMSs, improves performance and will simplify development. Requires changes to PI to be accepted by all PTs. See: https://wiki.egi.eu/wiki/Doctrine<br />
* Update current mutually-exclusive ‘EGI’ and ‘Local’ scope tags to be non-exclusive. Allows sites/services to be tagged multiple times with project-specific tags (e.g. ‘UK_NES’) and wider ‘EGI’ scope tags. Objects are created once. Maintains the integrity of topology information across different target infrastructures. PI ‘scope’ parameter value to support comma-separated list. Service scope values chosen from Site scope values. <br />
* Render GOCDB data in Glue2 XML and provide new PI method(s) to post downtimes using XML. Needed to address interoperability and data consistency across different info-systems/infrastructures. Has been requested by different stakeholders. <br />
<br />
====Impact on funding ====<br />
* Costs expected to stay constant up to April 2014 (aiming to address these developments and continue ops support at/around the current level). <br />
* Current level of match funding from GridPP is expected until April 2014. <br />
* Reducing costs before April 2014 is unrealistic. <br />
* Cost changes post April 2014 are hard to predict; depends on subsequent changes to requirements. Current level of match funding from GridPP is expected until 2015.<br />
<br />
== Operations Portal ==<br />
Partner: IN2P3<br />
===Current status===<br />
EGI.eu provides a central portal for the operations community that offers a bundle of different capabilities, such as the broadcast tool, VO management facilities, and a dashboard for grid operators that is used to display information about failing monitoring probes and to open tickets to the Resource Centres affected. The dashboard also supports the central grid oversight activities. It is fully interfaced with the EGI Helpdesk and the monitoring system through the message passing. It is a critical component as it is used by all EGI Operations Centres to provide support to the respective Resource Centres. <br />
<br />
=== Foreseen evolution ===<br />
<br />
<span style="line-height: 1.5em;">The Operations Portal is based on<br />
</span>lot of emerging technologies used in the Web development ( frameworks , Css templating system , javascript libraries ...) . <br />
<br />
The emergence of such technologies provide new opportunities to the users in terms of ergonomics , visualisation layer , services offer &nbsp;and bring also new usage and new possibliites of features. <br />
<br />
The Operations Portal team is following such evolutions and aiming&nbsp; at providing these opportunitites to the community if they are useful.<br> The portal has been designed in a modular way and as an aggregation plateform. The flexibility of the architecture allows for a&nbsp; huge&nbsp;number of data sources, and to provide standard access to information. <br />
<br />
The core of the data gathering system is the web service facility called Lavoisier. <br />
<br />
<span style="line-height: 1.5em;">Lavoisier’s<br />
</span>flexibility allows us to be ready to integrate almost any kind of new information if needed&nbsp;<span style="line-height: 1.5em;">and meaningful. For the new resource types coming into<br />
</span>the EGI production infrastructure, such as <br />
<br />
HPC systems, virtualized resources, desktop resources we are able&nbsp;to integrate its via plug-ins inside Lavoisier.<br> <br />
<br />
<br> <br />
<br />
==== Impact on funding ====<br />
<br />
<span style="line-height: 1.5em;">With the current level of<br />
</span>fundings (PY4) we can ensure the daily maintenance and we can provide only some improvements on the existing tool if developments are limited. <br />
<br />
<span style="line-height: 1.5em;">A decrease of funding after April 2014 will&nbsp; imply that </span><span style="line-height: 19.1875px;">additional development requirements<br />
</span>will not been taken into account and further developments to extend the current&nbsp;<span style="line-height: 19.1875px;">&nbsp;tool with new technologies and new source of<br />
</span>information will not be possible&nbsp; (HPC or cloud resources) . All new developments&nbsp; would also require new funding.<br><br />
<br />
== Metrics Portal ==<br />
Partner: CESGA <br />
===Current status===<br />
The Metrics Portal displays a set of metrics that will be used to monitor the performance of the <br />
infrastructure and the project, and to track their changes over time. The portal automatically collects <br />
all the required data and calculates these metrics before displaying them in the portal. The portal <br />
aggregates information from different sources such as GOCDB, GGUS, etc. <br />
<br />
The Metrics Portal has been used for the last year to gather metrics from the project tasks. Depending of changes on the structure and scope of the projects and its tasks and activities, the portal will be updated while keeping the old metrics in their validity periods. <br />
<br />
The Portal also monitorizes the evolution of the infrastructure month by month and it is the only way to have access to historic data on infrastructure evolution data (vs. realtime data).<br />
<br />
====Dependencies====<br />
The Metrics Portal has many dependencies. These include: <br />
<br />
* Accounting Portal: To display accounting metrics, most active VOs, Number of submitted jobs, etc. <br />
<br />
* BDII: Number of CPUs and Cores in production, online and nearline storage, mpi sites. <br />
<br />
* GGUS: Number of tickets created/closed. Tickets response times, Number of tickets created by priority, etc. <br />
<br />
* GOCDB: Sites in production, number of countries and NGIs in EGI. <br />
<br />
* ACE: Availability and reliability metrics. <br />
<br />
=== Foreseen evolution ===<br />
<br />
* Manual metrics expansion and refinement - In the line of having finer granularity and semantics to enable better user reporting.<br />
* Views enhancement and optimization - Crossbrowser integration, possibly AJAX functionality, mobile integration.<br />
* Regional portal codebase improvements - Refactoring, code documentation and quality improvement.<br />
* GGUS metrics improvement and new A/R metrics <br />
* Access Control improvements - Finer grained access mechanism.<br />
* New customized reports with Excel support <br />
<br />
=== Impact on funding ===<br />
The funding should remain constant until February 2014. After February 2014 the status, dedication and funding of staff maintaining the portal is not clear. The availability of National and regional funding is also uncertain, perhaps the situation will be clearer next year. To ensure continued operation, the funding would have to be maintained at the current level<br />
<br />
== Helpdesk ==<br />
Partner: KIT <br />
===Current status===<br />
EGI provides support to users and operators through a distributed helpdesk with central coordination (GGUS). The central helpdesk provides a single interface for support. The central system is interfaced to a variety of other ticketing systems at the NGI level in order to allow a bi-directional exchange of tickets (for example, those opened locally can be passed to the central instance or other areas, while user and operational problem tickets can be open centrally and subsequently routed to the NGI local support infrastructures).<br />
<br />
=== Foreseen evolution ===<br />
* GGUS Report Generator - Some fine tuning is still to be done. Another report [[https://rt.egi.eu/guest/Ticket/Display.html?id=4752 ETA accuracy]] needs implementation<br />
* VOMS synchronization - Restructuring VOMS synchronization for making it fail-safe.<br />
* GGUS Interfaces with other ticketing systems - Interfaces for PRACE/MAPPER, DANTE, NGI_IBERGRID<br />
* Alarm process for central operations tools - Implement alarm process for EGI central operations tools<br />
* Implementation of specific work flows for CSIRT/Security - The CSIRT team is currently evaluating whether they want to use GGUS. If CSIRT will use GGUS the permissions and access rights schema needs to be adapted to their needs.<br />
* Web portal - Introduce alternative authentication/authorization processes and provide specific view for CMS VO<br />
* Integration of operations portal in GGUS<br />
* Ticket monitoring in GGUS - Provide input on how processing tickets waiting for submitter's input and input on how processing tickets waiting for activity of technology providers after the end of EMI.<br />
<br />
<br><br />
<br />
=== Impact on funding ===<br />
<br />
<br><br />
<br />
== Core and Catch-all Services ==<br />
Parner: GRNET JRU<br />
<br />
===Current status===<br />
Auxiliary core services are needed for the good running of Infrastructure Services. Examples of such services are VOMS service and VO membership management for infrastructural VOs (DTEAM, OPS), the provisioning of middleware services needed by the monitoring infrastructure (e.g. top-BDII and WMS), the catch-all CA and other catch-all core services to support small user communities (central catalogues, workflow schedulers, authentication services).<br />
<br />
===Foreseen evolution ===<br />
This should include central SAM instances for ad-hoc monitoring objectives (like the middleware monitoring SAM).<br />
<br />
====Impact on funding ====<br />
<br />
= Resources =<br />
* Deliverable [https://documents.egi.eu/document/1471 D4.7]: Operations sustainability <br />
* [https://documents.egi.eu/document/1098 Seeking new horizons: EGI's role in 2020]<br />
* IMPORTANT. [https://wiki.egi.eu/wiki/File:EGIActionPlanV1.pdf | EGI Community Action Plan 2013 and beyond], EGI Council, Dec 2012</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI-InSPIRE:SA1_EGI_Global_tasks_evolution&diff=50323EGI-InSPIRE:SA1 EGI Global tasks evolution2013-01-25T10:05:59Z<p>Kouril: /* Security Monitoring Coordination */</p>
<hr />
<div>[[Category:EGI-inSPIRE SA1]]<br />
This document provided by the partners responsible of EGI operations global tasks provide information about current status and the envisaged evolution of these tasks '''after April 2014'''.<br />
<br />
=Human Services=<br />
==Operation Management Board Coordination==<br />
Partner: EGI.eu<br />
===Current status===<br />
The Operations Management Board (OMB) drives future developments in the operations area by making sure that the infrastructure delivers high availability, is secure, meets the demand of existing user communities and that infrastructure operations evolve to support the integration of new resource infrastructures. It does this by providing management and developing policies and procedures for the operational services that are integrated into the production infrastructure.<br />
The OMB is responsible of technical roadmapping and of the definition and execution of processes for periodic gathering of requirements.<br />
<br />
===Foreseen evolution ===<br />
<br />
====Impact on funding ====<br />
<br />
==Software Support ==<br />
<br />
===Current status===<br />
EGI.eu provides first and second level user and operations support and this function includes the following tasks:<br />
* function coordination (partner: CESNET)<br />
* ticket triage and assignment for dispatching of tickets to the appropriate SUs within GGUS (partners: INFN, CESNET)<br />
* 1st and 2nd level software support, encompassing both grid middleware and operational tools (operational tickets are dispatched to NGI operations SUs, so are not internally addressed by the software support team). This includes the production of howtos and reporting to operations meetings about critical incidents (partners: CESNET, INFN, JUELICH, LIU and STFC<br />
* Ticket oversight and follow-up (partner: KIT): this function includes administrative and reporting functions of the helpdesk infrastructure (e.g. collecting ticket statistics, internal and external reporting of statistics for SLAs monitoring and other reporting duties), and follow-up (notifying supporters when the reaction to high-priority tickets is not fast enough, requesting information from ticket submitters when they do not react, ensuring assigners/resolvers will react sufficiently fast when the submitter provides additional information).<br />
<br />
[https://documents.egi.eu/document/1104| More information about this task]<br />
<br />
===Foreseen evolution ===<br />
<br />
<br />
====Impact on funding ====<br />
<br />
=== Coordination of Grid Oversight ===<br />
Partners: SARA, CYFRONET<br />
<br />
===Current status===<br />
Grid Oversight is an activity aimed at controlling the infrastructure and solving arising operational issues. Theses issues can be of different complexity and importance, and may be caused by various reasons on regional or central level. For the scalability reasons the Grid Oversight has hierarchical structure: teams on regional (ROD) and central (COD) level contribute to it, solving problems within their scope. The COD part of the function is a global task.<br />
Speaking in ITSM terms the processes in which COD is naturally interested in are these of Service<br />
Operations area, especially Incident Management and Problem Management. The oversight of Incident<br />
Management is organized in an escalation process and COD is the body to which incidents that can not<br />
be handled on regional level are escalated.<br />
<br />
===Foreseen evolution ===<br />
After april 2014, there will be more emphasis on supporting NGIs, assistance of user communities with respect to resource allocation. This will be in addition to what is already being done today.<br />
* Read the [https://documents.egi.eu/document/1529 full proposal]<br />
<br />
====Impact on funding ====<br />
This is uncertain.<br />
<br />
== Coordination of network support, monitoring, troubleshooting ==<br />
Partner: GARR<br />
<br />
===Current status===<br />
Provides network support for the resolution of end-to-end network performance issues.<br />
EGI is a highly distributed networked infrastructure of grid services using network connectivity for remote job submission, data transfer and data access, hence tools are needed for network troubleshooting and performance monitoring<br />
<br />
===Foreseen evolution ===<br />
<br />
====Impact on funding ====<br />
<br />
== Coordination of Operational interoperation between NGIs and DCIs ==<br />
Partner: EGI.eu<br />
<br />
===Current status===<br />
EGI coordinates the integration of heterogeneous middleware stacks and Distributed Computing Infrastructures with the EGI operational infrastructures such as: accounting, monitoring, managemenet and support.<br />
<br />
===Foreseen evolution ===<br />
<br />
====Impact on funding ====<br />
<br />
== Coordination of documentation==<br />
Partner: EGI.eu<br />
<br />
===Current status===<br />
Coordination of maintenance and development operational documentation, procedures, best practices.<br />
<br />
===Foreseen evolution ===<br />
====Impact on funding ====<br />
<br />
== Security Operations Coordination ==<br />
Partners: STFC, NIKHEF<br />
<br />
(now including security policy coordination as this is closely related to operations)<br />
<br />
===Current status===<br />
<!-- add and modify text as needed. This paragraph should include: EGI CSIRT, security training, security drills, IRTF, SVG and if you want SPG --><br />
The inherent value of the e-Infrastructure provides a strong rationale for security coordination amongst the EGI participants at various levels. Central coordination of the security activities ensures that policies, operational security, and maintenance are compatible amongst all partners, improving availability and lowering access barriers for use of the infrastructure. Today, the Security Policy Group (SPG) coordinates a consistent set of security policies, developed in collaboration with all interested NGIs, and provides technical implementations of these policies for simplified use by the NGIs where relevant. In addition, security and incident response is provided through the EGI Computer Security and Incident Response Team (CSIRT) by coordinating activity in the NGIs and at the sites across the infrastructure. This coordination ensures that incidents are promptly and efficiently handled, that common policies are followed by providing services such as security monitoring, and by training and dissemination with the goal of improving the response to incidents. The overall incident response capabilities of the sites, also with respect to new technologies introduced by the user communities (VOs), such as the VO-Job-submission frameworks, are frequently assessed through the EGI-wide security drills.<br />
<br />
===Foreseen evolution ===<br />
Security is an ongoing process. Policies, procedures, operations, technology and trust have to constantly evolve to address new threats and risks. In the security threat risk assessment carried out in 2012 one of the threats highlighted as a high risk issue was “The move to more use of Cloud technologies may lead to security problems”. There is no doubt that there will be many issues to be solved in the provision of secure operations as we deploy new technologies, which we are sure will require at least the current level of effort to manage and co-ordinate. We have decided to request the effort we will need for global coordination of security for EGI, based on what we are currently doing and the foreseen future needs. We are convinced that we will continue to need at least this level of effort and that this will need to be funded somehow.<br />
<br />
Experience of providing such security coordination over the last two years has shown that this includes multiple aspects that can be more clearly distinguished when evolving the task for the future, as presented in the following sub-sections.<br />
<br />
====Security Policy Coordination and the support of its implementation====<br />
Security policy development covers diverse aspects, including operational<br />
policies (agreements on vulnerability management, intrusion detection and<br />
prevention, regulation of access, and enforcement), incident response policies<br />
(governing the exchange of information and expected actions), participant<br />
responsibilities (including acceptable use policies, identifying users and<br />
managing user communities), traceability, legal aspects, and the protection<br />
of personal data. In an environment without central control, such as EGI,<br />
common identity management such as provided by the IGTF, is needed to ensure<br />
unique and persistent assignments of rights and privileges. Since research is<br />
global, such policies must be coordinated with peer infrastructures in Europe<br />
and elsewhere, such as PRACE-RI, Open Science Grid, XSEDE, and like efforts in<br />
the Asia Pacific. Coordination mechanisms such as the FIM4R group, TERENA<br />
REFEDS, SCI, Open Grid Forum and the IGTF are employed.<br />
For some elements of these policies (such as the common identity management)<br />
having a central reference implementation for immediate re-use by the NGIs<br />
saves on total effort needed in the long run. The use today of the centrally<br />
produced "EGI trust anchor distribution" is expected to continue.<br />
<br />
====Incident Response Task Force (IRTF) coordination and advanced incident response====<br />
Experience has shown that the complexity of multi-domain incidents at the<br />
scale of EGI necessitates dedicated experts in incident response and forensics<br />
to deal with global incidents and to provide support to EGI participants to<br />
address localised incidents before they spread across EGI. Experience with the<br />
rotational scheme used today in EGI has shown that it is<br />
very hard to retain unique expertise in a widely distributed community with<br />
high personnel turn-over. In practice, incident response is provided by a<br />
dedicated core team, with specialist forensics support concentrated in just a<br />
few individuals. It is essential that this expertise is available as and when<br />
needed, but it cannot provide global coverage for any EGI site. <br />
We propose to establish a small core team which holds the coordination<br />
role and provides advanced support in incident response and forensics.<br />
The primary responsibility for basic incident response and forensics<br />
will still lie with each NGI, while the EGI Global IRTF will coordinate<br />
incident response and information exchange. However, for complex<br />
multi-site incidents and in cases where advanced forensics is needed,<br />
the EGI Global IRTF will step in and take an active part, to protect the<br />
continued integrity of the EGI infrastructure as a whole. Investment in<br />
a relatively small amount of global coordination effort, removes the<br />
need for each NGI to have to maintain its own specialist IT security<br />
capability and has the potential to realise cost savings within each NGI.<br />
<br />
====Software Vulnerability (SVG) coordination====<br />
The Software Vulnerability Group (SVG) aims at eliminating existing vulnerabilities from the deployed infrastructure, primarily from the grid middleware, and avoiding the introduction of new ones, thus preventing security incidents. This activity will need to continue both to handle new vulnerabilities found in the Grid middleware currently deployed, and to handle vulnerabilities in software used by future technology to facilitate the sharing of distributed resources such as federated clouds. The SVG handles vulnerabilities reported in software used specifically in the EGI infrastructure. This depends on investigation and risk assessment by a collaborative team drawn from technology providers and other security groups, known as the Risk Assessment Team or 'RAT'. Considering the recent number of vulnerabilities detected and the co-ordination effort needed with other entities (Technology providers, EGI software distribution managers and coordinators, and central operations co-ordination) this task needs explicit recognition and assignment of dedicated effort. In particular the SVG also has a role in determining the threat posed by software deployed in the infrastructure independent of specific vulnerability events. SVG also has a role in the co-ordination and prioritization of 'Vulnerability Assessment' work, which is the examination of software to find whether any vulnerabilities exist. The SVG has also been asked to assess or advise on the assessment of other pieces of software prior to recommending their deployment on the EGI infrastructure, but has insufficient manpower to carry this out. <br />
<br />
====Security Coordination through Security Service Challenges and Training====<br />
Participating in a global infrastructure is still not a very common task for<br />
some resource centres. Unless specific efforts are made to ensure communication on<br />
incidents is effective between all EGI participants, the 'weakest link'<br />
principle applies and the integrity of the entire infrastructure can<br />
inadvertently be put at risk by a single user or resource. The use of<br />
'security drills', exercising the incident response communications channels,<br />
has proven particularly effective in ensuring open and effective exchange of<br />
information. Additionally, these security drills can be re-used at a site or<br />
national level, where they serve as trainings in computer security forensics<br />
and identification of intrusion and threats.<br />
To be effective, the security drills must be realistic, current with respect<br />
to the software and intrusion vectors used to exercise the site, and be based<br />
on the actual communication infrastructure of EGI. The drills need development<br />
(mainly contributed) and periodic use in realistic tests (the coordination<br />
function included here). Re-using the security drills for training and<br />
national (re)use needs limited 'train the trainer' effort which is best<br />
provided for centrally.<br />
<br />
====Security Monitoring Coordination====<br />
EGI is an interconnected federation where a single vulnerable place may<br />
have a huge impact on the whole infrastructure. In order to recognize<br />
the risks and to address potential vulnerabilities in a timely manner,<br />
the EGI Security Monitoring provides an oversight of the infrastructure<br />
from the security standpoint. Also, sites connected to EGI differ<br />
significantly in the level of security and detecting weaknesses exposed<br />
by the sites allows the EGI security operations to contact the sites<br />
before the issue leads to an incident. Information produced by security<br />
monitoring is also important during assessment of new risks and<br />
vulnerabilities since it enables to identify the scope and impact of a<br />
potential security incident. The whole activity needs to be closely linked to other<br />
security-related tasks, namely the Incident Response Task Force and SVG<br />
and provide reliable and quick support to them (for instance to<br />
introduce new checks or process collected data). The task needs to<br />
cooperate with other activities responsible for general EGI monitoring<br />
and will need to coordinate their developments among these activities. Additional<br />
connections need to be maintained to the operations dashboard and<br />
common activities doing support to sites to make sure detected security issues<br />
are handled properly.<br />
<br />
Development/maintenance of security monitoring is described in the dedicated section on [[#Security Monitoring|security monitoring]].<br />
<br />
===Impact on funding ===<br />
It has already been acknowledged that some areas of security coordination are underfunded today in EGI-InSPIRE. Lack of global effort in the Incident Response Team is a growing problem and the amount of global effort to coordinate SVG (currently 1 PM/year) is way too small. We have therefore decided to give honest estimates of the amount of effort required to perform adequate global coordination of security in EGI. <br />
<br />
Experience over the last 2 years in EGI-InSPIRE has established that the amount of global coordination effort required to perform these critical duties is as follows.<br />
<br />
Person-Months per year, total effort: [partners to be assigned]<br />
<br />
*6+2 PM Security policy coordination and the support of its implementation<br />
*12 PM IRTF coordination and advanced incident response<br />
*6 PM SVG coordination<br />
*6 PM Security coordination through service challenges and training<br />
*4 PM Security monitoring coordination <br />
<br />
Total effort required 36 PM/year.<br />
<br />
== Service Level Management: availability/reliability reports==<br />
Partner: AUTH <br />
=== Current Status ===<br />
This task includes the validation of distribution of monthly availability statistics for Resource Centres, NGIs, EGI.eu, and the coordination of the evolution of the EGI OLA framework and the related reporting tools.<br />
<br />
===Foreseen evolution ===<br />
====Impact on funding ====<br />
<br />
=Infrastructure Services=<br />
<br />
==Software Rollout==<br />
Partner: LIP<br />
<br />
===Current status ===<br />
Updates of deployed software need to be gradually adopted in production after internal verification. This process is implemented in EGI through staged rollout, i.e. through the early deployment of a new component by a selected list of candidate Resource Centres. The successful verification of a new component is a precondition for declaring the software ready for deployment. Given the scale of the EGI infrastructure, this process requires careful coordination to ensure that every new capability is verified by a representative pool of candidate sites, to supervise the responsiveness of the candidate sites and ensure that the staged rollout progresses well without introducing unnecessary delays, and to review the reports produced. It also ensures the planning of resources according to the foreseen release schedules from the Technology Providers. EGI.eu coordination is necessary to ensure a successful interoperation of the various stakeholders: Resource Centres, Technology Providers, the EGI.eu Technical Manager and the EGI repository managers.<br />
<br />
This activities includes:<br />
* Definition and adoption of a workflow to automate software deployment <br />
* Coordination of the staged rollout activities carried out by the NGIs<br />
* Liaison with the UMD team (EGI-InSPIRE SA2)and the Products Teams<br />
<br />
===Foreseen evolution ===<br />
====Impact on funding ====<br />
<br />
== Monitoring ==<br />
=== Central SAM monitoring services===<br />
Partner: CERN <br />
====Current status====<br />
A distributed monitoring framework is necessary to continuously test the level of functionality delivered by each service node instance in the production Resource Centres, to generate alarms and tickets in case of critical failures and to compute monthly availability and reliability statistics, and to monitor and troubleshoot network problems. The Monitoring Infrastructure is a distributed service based on Nagios and messaging. The central services – operated by EGI.eu – include systems such as the MyEGI portal for the visualisation of information, and a set of databases for the persistent storage of information about test results, availability statistics, monitoring profiles and aggregated topology information. The central services need to interact with the local monitoring infrastructures operated by the NGIs. The central monitoring services are critical and need to deliver high availability.<br />
<br />
====Foreseen evolution ====<br />
=====Impact on funding =====<br />
<br />
<br />
=== Broker network=== <br />
Partner: GRNET (coord), SRCE, CERN <br />
====Current status====<br />
====Foreseen evolution ====<br />
=====Impact on funding =====<br />
<br />
<br />
== Accounting ==<br />
<br />
=== APEL central DB ===<br />
Partner: STFC<br />
<br />
====Current status====<br />
The EGI Accounting Infrastructure is distributed. At a central level it includes the repositories for the persistent storage of usage records. The Accounting Infrastructure is essential in a service-oriented business model to record usage information. Accounting data needs to be validated and regularly published centrally. The central databases are populated through individual usage records published by the Resource Centres, or through the publication of summarised usage records.<br />
<br />
===== Dependencies =====<br />
The Accounting Repository has a number of dependencies on other EGI tools:<br />
* Accounting Portal<br />
* GOCDB<br />
* EGI Message Brokers<br />
* GGUS<br />
* Operations Portal and Operations Dashboard<br />
<br />
====Foreseen evolution ====<br />
2013/2014 Technical Evolution: <br />
* Accounting’s evolution over the final year of EGI-InSPIRE will be to consolidate the new Accounting repository to receive records from the EMI APEL 3 client, from the regional APEL server implementations and from other CPU accounting sources (MAPPER, EDGI, UNICORE etc.). Additionally, the archived data in summary form will be migrated to the new format.<br />
* Other types of accounting (Cloud, Storage, Application etc.) is in early testing stage for the accounting repository, although the SSM publishing method has proved robust and usable in these new contexts. Next steps for the coming year are to test with multiple clients ensuring their representation of data is consistent from one client to another and producing summaries for the portal to publish.<br />
<br />
By the end of EGI-InSPIRE we will have implemented the new accounting system to receive and publish records from multiple clients, including a regional APEL server, and for multiple types of accounting.<br />
<br />
* Integration of accounting records from different types of accounting is the next step which would continue after EGI-InSPIRE if funding is available, as this is not yet in development. The implementation of storage accounting integrated with cloud accounting, for example, can only realistically be worked on once we have a body of data from the storage and cloud clients which may be related. Similarly for cloud/cpu and cloud/application integration. The feasibility of this integration requires some research which I envisage could not start until earliest Q3 2013 and would expect it to extend beyond EGI-InSPIRE. <br />
<br />
=====Impact on funding =====<br />
* Costs expected to stay constant up to April 2014 (aiming to address the developments set out in the first two bullets above and continue maintenance and support at the current level). <br />
* Current level of match funding from GridPP is expected until April 2014. <br />
* Reducing costs before April 2014 is unrealistic.<br />
* Current level of match funding from GridPP is expected until 2015.<br />
* Post-April 2013 - if there are additional development requirements then funding for these will be required, this would be for further developments in other types of accounting (Cloud, Storage, Application etc.). It is expected that requirements for these would evolve as their usage increases and this will require work beyond maintenance and operations. If the evolution of accounting is to include the integration of data from different types of accounting then this would also require further funding.<br />
<br />
=== Central accounting portal ===<br />
Partner: CESGA<br />
<br />
====Current status====<br />
The EGI accounting infrastructure is a complex system that involves various sensors in different <br />
regions, all publishing data to a central repository. The data is processed, summarized and displayed <br />
in the Accounting Portal, which acts as a common interface to the different accounting record <br />
providers and presents a homogeneous view of the data gathered and a user-friendly access to <br />
understanding resource utilisation.<br />
<br />
The current production version (v4.2 Fomalhaut) of the Accounting Portal is available at https://accounting.egi.eu. The regional Accounting Portal is ready, pending support from APEL regionalization.<br />
<br />
=====Dependencies=====<br />
The Accounting Portal has functional dependencies on the following tools: <br />
<br />
* GOCDB: List of sites and NGIs in production, list of available services in production. <br />
<br />
* CIC Portal: VOMS endpoints and VO list. <br />
<br />
* Accounting Repository: Accounting records and summarized accounting data.<br />
<br />
====Foreseen evolution ====<br />
In the period 2013/2014, the following directions are planned:<br />
* Contributed CPUs by site - Measuring the contribution in CPUs vs the number of hours, enhancing the reporting existing now with SPECInts.<br />
* Preliminar support for parallel (MPI) jobs - There were advances in this after the MPI vt lifespan, but further software development is needed.<br />
* New Accounting: Integration of all advances on Network, Storage and Application accounting on JRA1.4, apart from possible new developments that may arise.<br />
* EGI User usage accounting - Improvements on the userDN accounting.<br />
* Preliminar cloud support - Display and integration of the experimental sites offering cloud computing capabilities under the fedcloud task.<br />
* Regional portal codebase improvements - Implantation and improvement based on regional experiences if appropriate.<br />
* XML endpoints generalization and improvement - Implementation of a friendlier XML interface and documentation for users wishing programmatic access<br />
* Cloud support improvements - Further integration of cloud accounting characteristics.<br />
<br />
=====Impact on funding =====<br />
The funding should remain constant until February 2014. <br />
After February 2014 the status, dedication and funding of staff maintaining the portal is not clear. The availability of National and regional funding is also uncertain, perhaps the situation will be clearer next year.<br />
To ensure continued operation, the funding would have to be maintained at the current level<br />
<br />
== Security Monitoring ==<br />
* Security Nagios server. Partner: GRNET <br />
* CSIRT Pakiti. Partner CESNET <br />
<br />
===Current status ===<br />
The objective of a Security Infrastructure is to protect itself from intrusions such as exploitable software vulnerabilities, misuse by authorised users, resource "theft", etc., while allowing the information, resources and services to remain accessible and productive to its intended users. A specifically designed set of tools and services help reduce these vulnerabilities such as monitoring individual resource centers (based on Nagios and Pakiti), a central security dashboard to allow sites, NGIs and EGI Computer Security Incident Response Teams to access security alerts in a controlled manner, and a ticketing system to support coordination efforts.<br />
<br />
===Foreseen evolution ===<br />
====Impact on funding ====<br />
<br />
== Configuration Repository (GOCDB) ==<br />
Partner: STFC <br />
===Current status===<br />
EGI relies on a central database (GOCDB) to record static information about different entities such as the Operations Centres, the Resource Centres, and the service instances. It also provides contact, role and status information. GOCDB is a source of information for many other operational tools, such as the broadcast tool, the Aggregated Topology Provider, etc.<br />
<br />
===Foreseen evolution ===<br />
1yr Technical Evolution: <br />
GOCDB needs to evolve along the following themes to address current and emerging stakeholder requirements: <br />
* GOCDB v5 (~April/May). Replaces Oracle PROM database with ORM DB objects. Is needed to support different RDBMSs, improves performance and will simplify development. Requires changes to PI to be accepted by all PTs. See: https://wiki.egi.eu/wiki/Doctrine<br />
* Update current mutually-exclusive ‘EGI’ and ‘Local’ scope tags to be non-exclusive. Allows sites/services to be tagged multiple times with project-specific tags (e.g. ‘UK_NES’) and wider ‘EGI’ scope tags. Objects are created once. Maintains the integrity of topology information across different target infrastructures. PI ‘scope’ parameter value to support comma-separated list. Service scope values chosen from Site scope values. <br />
* Render GOCDB data in Glue2 XML and provide new PI method(s) to post downtimes using XML. Needed to address interoperability and data consistency across different info-systems/infrastructures. Has been requested by different stakeholders. <br />
<br />
====Impact on funding ====<br />
* Costs expected to stay constant up to April 2014 (aiming to address these developments and continue ops support at/around the current level). <br />
* Current level of match funding from GridPP is expected until April 2014. <br />
* Reducing costs before April 2014 is unrealistic. <br />
* Cost changes post April 2014 are hard to predict; depends on subsequent changes to requirements. Current level of match funding from GridPP is expected until 2015.<br />
<br />
== Operations Portal ==<br />
Partner: IN2P3<br />
===Current status===<br />
EGI.eu provides a central portal for the operations community that offers a bundle of different capabilities, such as the broadcast tool, VO management facilities, and a dashboard for grid operators that is used to display information about failing monitoring probes and to open tickets to the Resource Centres affected. The dashboard also supports the central grid oversight activities. It is fully interfaced with the EGI Helpdesk and the monitoring system through the message passing. It is a critical component as it is used by all EGI Operations Centres to provide support to the respective Resource Centres. <br />
<br />
=== Foreseen evolution ===<br />
<br />
<span style="line-height: 1.5em;">The Operations Portal is based on<br />
</span>lot of emerging technologies used in the Web development ( frameworks , Css templating system , javascript libraries ...) . <br />
<br />
The emergence of such technologies provide new opportunities to the users in terms of ergonomics , visualisation layer , services offer &nbsp;and bring also new usage and new possibliites of features. <br />
<br />
The Operations Portal team is following such evolutions and aiming&nbsp; at providing these opportunitites to the community if they are useful.<br> The portal has been designed in a modular way and as an aggregation plateform. The flexibility of the architecture allows for a&nbsp; huge&nbsp;number of data sources, and to provide standard access to information. <br />
<br />
The core of the data gathering system is the web service facility called Lavoisier. <br />
<br />
<span style="line-height: 1.5em;">Lavoisier’s<br />
</span>flexibility allows us to be ready to integrate almost any kind of new information if needed&nbsp;<span style="line-height: 1.5em;">and meaningful. For the new resource types coming into<br />
</span>the EGI production infrastructure, such as <br />
<br />
HPC systems, virtualized resources, desktop resources we are able&nbsp;to integrate its via plug-ins inside Lavoisier.<br> <br />
<br />
<br> <br />
<br />
==== Impact on funding ====<br />
<br />
<span style="line-height: 1.5em;">With the current level of<br />
</span>fundings (PY4) we can ensure the daily maintenance and we can provide only some improvements on the existing tool if developments are limited. <br />
<br />
<span style="line-height: 1.5em;">A decrease of funding after April 2014 will&nbsp; imply that </span><span style="line-height: 19.1875px;">additional development requirements<br />
</span>will not been taken into account and further developments to extend the current&nbsp;<span style="line-height: 19.1875px;">&nbsp;tool with new technologies and new source of<br />
</span>information will not be possible&nbsp; (HPC or cloud resources) . All new developments&nbsp; would also require new funding.<br><br />
<br />
== Metrics Portal ==<br />
Partner: CESGA <br />
===Current status===<br />
The Metrics Portal displays a set of metrics that will be used to monitor the performance of the <br />
infrastructure and the project, and to track their changes over time. The portal automatically collects <br />
all the required data and calculates these metrics before displaying them in the portal. The portal <br />
aggregates information from different sources such as GOCDB, GGUS, etc. <br />
<br />
The Metrics Portal has been used for the last year to gather metrics from the project tasks. Depending of changes on the structure and scope of the projects and its tasks and activities, the portal will be updated while keeping the old metrics in their validity periods. <br />
<br />
The Portal also monitorizes the evolution of the infrastructure month by month and it is the only way to have access to historic data on infrastructure evolution data (vs. realtime data).<br />
<br />
====Dependencies====<br />
The Metrics Portal has many dependencies. These include: <br />
<br />
* Accounting Portal: To display accounting metrics, most active VOs, Number of submitted jobs, etc. <br />
<br />
* BDII: Number of CPUs and Cores in production, online and nearline storage, mpi sites. <br />
<br />
* GGUS: Number of tickets created/closed. Tickets response times, Number of tickets created by priority, etc. <br />
<br />
* GOCDB: Sites in production, number of countries and NGIs in EGI. <br />
<br />
* ACE: Availability and reliability metrics. <br />
<br />
=== Foreseen evolution ===<br />
<br />
* Manual metrics expansion and refinement - In the line of having finer granularity and semantics to enable better user reporting.<br />
* Views enhancement and optimization - Crossbrowser integration, possibly AJAX functionality, mobile integration.<br />
* Regional portal codebase improvements - Refactoring, code documentation and quality improvement.<br />
* GGUS metrics improvement and new A/R metrics <br />
* Access Control improvements - Finer grained access mechanism.<br />
* New customized reports with Excel support <br />
<br />
=== Impact on funding ===<br />
The funding should remain constant until February 2014. After February 2014 the status, dedication and funding of staff maintaining the portal is not clear. The availability of National and regional funding is also uncertain, perhaps the situation will be clearer next year. To ensure continued operation, the funding would have to be maintained at the current level<br />
<br />
== Helpdesk ==<br />
Partner: KIT <br />
===Current status===<br />
EGI provides support to users and operators through a distributed helpdesk with central coordination (GGUS). The central helpdesk provides a single interface for support. The central system is interfaced to a variety of other ticketing systems at the NGI level in order to allow a bi-directional exchange of tickets (for example, those opened locally can be passed to the central instance or other areas, while user and operational problem tickets can be open centrally and subsequently routed to the NGI local support infrastructures).<br />
<br />
=== Foreseen evolution ===<br />
* GGUS Report Generator - Some fine tuning is still to be done. Another report [[https://rt.egi.eu/guest/Ticket/Display.html?id=4752 ETA accuracy]] needs implementation<br />
* VOMS synchronization - Restructuring VOMS synchronization for making it fail-safe.<br />
* GGUS Interfaces with other ticketing systems - Interfaces for PRACE/MAPPER, DANTE, NGI_IBERGRID<br />
* Alarm process for central operations tools - Implement alarm process for EGI central operations tools<br />
* Implementation of specific work flows for CSIRT/Security - The CSIRT team is currently evaluating whether they want to use GGUS. If CSIRT will use GGUS the permissions and access rights schema needs to be adapted to their needs.<br />
* Web portal - Introduce alternative authentication/authorization processes and provide specific view for CMS VO<br />
* Integration of operations portal in GGUS<br />
* Ticket monitoring in GGUS - Provide input on how processing tickets waiting for submitter's input and input on how processing tickets waiting for activity of technology providers after the end of EMI.<br />
<br />
<br><br />
<br />
=== Impact on funding ===<br />
<br />
<br><br />
<br />
== Core and Catch-all Services ==<br />
Parner: GRNET JRU<br />
<br />
===Current status===<br />
Auxiliary core services are needed for the good running of Infrastructure Services. Examples of such services are VOMS service and VO membership management for infrastructural VOs (DTEAM, OPS), the provisioning of middleware services needed by the monitoring infrastructure (e.g. top-BDII and WMS), the catch-all CA and other catch-all core services to support small user communities (central catalogues, workflow schedulers, authentication services).<br />
<br />
===Foreseen evolution ===<br />
This should include central SAM instances for ad-hoc monitoring objectives (like the middleware monitoring SAM).<br />
<br />
====Impact on funding ====<br />
<br />
= Resources =<br />
* Deliverable [https://documents.egi.eu/document/1471 D4.7]: Operations sustainability <br />
* [https://documents.egi.eu/document/1098 Seeking new horizons: EGI's role in 2020]<br />
* IMPORTANT. [https://wiki.egi.eu/wiki/File:EGIActionPlanV1.pdf | EGI Community Action Plan 2013 and beyond], EGI Council, Dec 2012</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI-InSPIRE:SA1_EGI_Global_tasks_evolution&diff=50322EGI-InSPIRE:SA1 EGI Global tasks evolution2013-01-25T10:05:12Z<p>Kouril: /* Security Monitoring Coordination */</p>
<hr />
<div>[[Category:EGI-inSPIRE SA1]]<br />
This document provided by the partners responsible of EGI operations global tasks provide information about current status and the envisaged evolution of these tasks '''after April 2014'''.<br />
<br />
=Human Services=<br />
==Operation Management Board Coordination==<br />
Partner: EGI.eu<br />
===Current status===<br />
The Operations Management Board (OMB) drives future developments in the operations area by making sure that the infrastructure delivers high availability, is secure, meets the demand of existing user communities and that infrastructure operations evolve to support the integration of new resource infrastructures. It does this by providing management and developing policies and procedures for the operational services that are integrated into the production infrastructure.<br />
The OMB is responsible of technical roadmapping and of the definition and execution of processes for periodic gathering of requirements.<br />
<br />
===Foreseen evolution ===<br />
<br />
====Impact on funding ====<br />
<br />
==Software Support ==<br />
<br />
===Current status===<br />
EGI.eu provides first and second level user and operations support and this function includes the following tasks:<br />
* function coordination (partner: CESNET)<br />
* ticket triage and assignment for dispatching of tickets to the appropriate SUs within GGUS (partners: INFN, CESNET)<br />
* 1st and 2nd level software support, encompassing both grid middleware and operational tools (operational tickets are dispatched to NGI operations SUs, so are not internally addressed by the software support team). This includes the production of howtos and reporting to operations meetings about critical incidents (partners: CESNET, INFN, JUELICH, LIU and STFC<br />
* Ticket oversight and follow-up (partner: KIT): this function includes administrative and reporting functions of the helpdesk infrastructure (e.g. collecting ticket statistics, internal and external reporting of statistics for SLAs monitoring and other reporting duties), and follow-up (notifying supporters when the reaction to high-priority tickets is not fast enough, requesting information from ticket submitters when they do not react, ensuring assigners/resolvers will react sufficiently fast when the submitter provides additional information).<br />
<br />
[https://documents.egi.eu/document/1104| More information about this task]<br />
<br />
===Foreseen evolution ===<br />
<br />
<br />
====Impact on funding ====<br />
<br />
=== Coordination of Grid Oversight ===<br />
Partners: SARA, CYFRONET<br />
<br />
===Current status===<br />
Grid Oversight is an activity aimed at controlling the infrastructure and solving arising operational issues. Theses issues can be of different complexity and importance, and may be caused by various reasons on regional or central level. For the scalability reasons the Grid Oversight has hierarchical structure: teams on regional (ROD) and central (COD) level contribute to it, solving problems within their scope. The COD part of the function is a global task.<br />
Speaking in ITSM terms the processes in which COD is naturally interested in are these of Service<br />
Operations area, especially Incident Management and Problem Management. The oversight of Incident<br />
Management is organized in an escalation process and COD is the body to which incidents that can not<br />
be handled on regional level are escalated.<br />
<br />
===Foreseen evolution ===<br />
After april 2014, there will be more emphasis on supporting NGIs, assistance of user communities with respect to resource allocation. This will be in addition to what is already being done today.<br />
* Read the [https://documents.egi.eu/document/1529 full proposal]<br />
<br />
====Impact on funding ====<br />
This is uncertain.<br />
<br />
== Coordination of network support, monitoring, troubleshooting ==<br />
Partner: GARR<br />
<br />
===Current status===<br />
Provides network support for the resolution of end-to-end network performance issues.<br />
EGI is a highly distributed networked infrastructure of grid services using network connectivity for remote job submission, data transfer and data access, hence tools are needed for network troubleshooting and performance monitoring<br />
<br />
===Foreseen evolution ===<br />
<br />
====Impact on funding ====<br />
<br />
== Coordination of Operational interoperation between NGIs and DCIs ==<br />
Partner: EGI.eu<br />
<br />
===Current status===<br />
EGI coordinates the integration of heterogeneous middleware stacks and Distributed Computing Infrastructures with the EGI operational infrastructures such as: accounting, monitoring, managemenet and support.<br />
<br />
===Foreseen evolution ===<br />
<br />
====Impact on funding ====<br />
<br />
== Coordination of documentation==<br />
Partner: EGI.eu<br />
<br />
===Current status===<br />
Coordination of maintenance and development operational documentation, procedures, best practices.<br />
<br />
===Foreseen evolution ===<br />
====Impact on funding ====<br />
<br />
== Security Operations Coordination ==<br />
Partners: STFC, NIKHEF<br />
<br />
(now including security policy coordination as this is closely related to operations)<br />
<br />
===Current status===<br />
<!-- add and modify text as needed. This paragraph should include: EGI CSIRT, security training, security drills, IRTF, SVG and if you want SPG --><br />
The inherent value of the e-Infrastructure provides a strong rationale for security coordination amongst the EGI participants at various levels. Central coordination of the security activities ensures that policies, operational security, and maintenance are compatible amongst all partners, improving availability and lowering access barriers for use of the infrastructure. Today, the Security Policy Group (SPG) coordinates a consistent set of security policies, developed in collaboration with all interested NGIs, and provides technical implementations of these policies for simplified use by the NGIs where relevant. In addition, security and incident response is provided through the EGI Computer Security and Incident Response Team (CSIRT) by coordinating activity in the NGIs and at the sites across the infrastructure. This coordination ensures that incidents are promptly and efficiently handled, that common policies are followed by providing services such as security monitoring, and by training and dissemination with the goal of improving the response to incidents. The overall incident response capabilities of the sites, also with respect to new technologies introduced by the user communities (VOs), such as the VO-Job-submission frameworks, are frequently assessed through the EGI-wide security drills.<br />
<br />
===Foreseen evolution ===<br />
Security is an ongoing process. Policies, procedures, operations, technology and trust have to constantly evolve to address new threats and risks. In the security threat risk assessment carried out in 2012 one of the threats highlighted as a high risk issue was “The move to more use of Cloud technologies may lead to security problems”. There is no doubt that there will be many issues to be solved in the provision of secure operations as we deploy new technologies, which we are sure will require at least the current level of effort to manage and co-ordinate. We have decided to request the effort we will need for global coordination of security for EGI, based on what we are currently doing and the foreseen future needs. We are convinced that we will continue to need at least this level of effort and that this will need to be funded somehow.<br />
<br />
Experience of providing such security coordination over the last two years has shown that this includes multiple aspects that can be more clearly distinguished when evolving the task for the future, as presented in the following sub-sections.<br />
<br />
====Security Policy Coordination and the support of its implementation====<br />
Security policy development covers diverse aspects, including operational<br />
policies (agreements on vulnerability management, intrusion detection and<br />
prevention, regulation of access, and enforcement), incident response policies<br />
(governing the exchange of information and expected actions), participant<br />
responsibilities (including acceptable use policies, identifying users and<br />
managing user communities), traceability, legal aspects, and the protection<br />
of personal data. In an environment without central control, such as EGI,<br />
common identity management such as provided by the IGTF, is needed to ensure<br />
unique and persistent assignments of rights and privileges. Since research is<br />
global, such policies must be coordinated with peer infrastructures in Europe<br />
and elsewhere, such as PRACE-RI, Open Science Grid, XSEDE, and like efforts in<br />
the Asia Pacific. Coordination mechanisms such as the FIM4R group, TERENA<br />
REFEDS, SCI, Open Grid Forum and the IGTF are employed.<br />
For some elements of these policies (such as the common identity management)<br />
having a central reference implementation for immediate re-use by the NGIs<br />
saves on total effort needed in the long run. The use today of the centrally<br />
produced "EGI trust anchor distribution" is expected to continue.<br />
<br />
====Incident Response Task Force (IRTF) coordination and advanced incident response====<br />
Experience has shown that the complexity of multi-domain incidents at the<br />
scale of EGI necessitates dedicated experts in incident response and forensics<br />
to deal with global incidents and to provide support to EGI participants to<br />
address localised incidents before they spread across EGI. Experience with the<br />
rotational scheme used today in EGI has shown that it is<br />
very hard to retain unique expertise in a widely distributed community with<br />
high personnel turn-over. In practice, incident response is provided by a<br />
dedicated core team, with specialist forensics support concentrated in just a<br />
few individuals. It is essential that this expertise is available as and when<br />
needed, but it cannot provide global coverage for any EGI site. <br />
We propose to establish a small core team which holds the coordination<br />
role and provides advanced support in incident response and forensics.<br />
The primary responsibility for basic incident response and forensics<br />
will still lie with each NGI, while the EGI Global IRTF will coordinate<br />
incident response and information exchange. However, for complex<br />
multi-site incidents and in cases where advanced forensics is needed,<br />
the EGI Global IRTF will step in and take an active part, to protect the<br />
continued integrity of the EGI infrastructure as a whole. Investment in<br />
a relatively small amount of global coordination effort, removes the<br />
need for each NGI to have to maintain its own specialist IT security<br />
capability and has the potential to realise cost savings within each NGI.<br />
<br />
====Software Vulnerability (SVG) coordination====<br />
The Software Vulnerability Group (SVG) aims at eliminating existing vulnerabilities from the deployed infrastructure, primarily from the grid middleware, and avoiding the introduction of new ones, thus preventing security incidents. This activity will need to continue both to handle new vulnerabilities found in the Grid middleware currently deployed, and to handle vulnerabilities in software used by future technology to facilitate the sharing of distributed resources such as federated clouds. The SVG handles vulnerabilities reported in software used specifically in the EGI infrastructure. This depends on investigation and risk assessment by a collaborative team drawn from technology providers and other security groups, known as the Risk Assessment Team or 'RAT'. Considering the recent number of vulnerabilities detected and the co-ordination effort needed with other entities (Technology providers, EGI software distribution managers and coordinators, and central operations co-ordination) this task needs explicit recognition and assignment of dedicated effort. In particular the SVG also has a role in determining the threat posed by software deployed in the infrastructure independent of specific vulnerability events. SVG also has a role in the co-ordination and prioritization of 'Vulnerability Assessment' work, which is the examination of software to find whether any vulnerabilities exist. The SVG has also been asked to assess or advise on the assessment of other pieces of software prior to recommending their deployment on the EGI infrastructure, but has insufficient manpower to carry this out. <br />
<br />
====Security Coordination through Security Service Challenges and Training====<br />
Participating in a global infrastructure is still not a very common task for<br />
some resource centres. Unless specific efforts are made to ensure communication on<br />
incidents is effective between all EGI participants, the 'weakest link'<br />
principle applies and the integrity of the entire infrastructure can<br />
inadvertently be put at risk by a single user or resource. The use of<br />
'security drills', exercising the incident response communications channels,<br />
has proven particularly effective in ensuring open and effective exchange of<br />
information. Additionally, these security drills can be re-used at a site or<br />
national level, where they serve as trainings in computer security forensics<br />
and identification of intrusion and threats.<br />
To be effective, the security drills must be realistic, current with respect<br />
to the software and intrusion vectors used to exercise the site, and be based<br />
on the actual communication infrastructure of EGI. The drills need development<br />
(mainly contributed) and periodic use in realistic tests (the coordination<br />
function included here). Re-using the security drills for training and<br />
national (re)use needs limited 'train the trainer' effort which is best<br />
provided for centrally.<br />
<br />
====Security Monitoring Coordination====<br />
EGI is an interconnected federation where a single vulnerable place may<br />
have a huge impact on the whole infrastructure. In order to recognize<br />
the risks and to address potential vulnerabilities in a timely manner,<br />
the EGI Security Monitoring provides an oversight of the infrastructure<br />
from the security standpoint. Also, sites connected to EGI differ<br />
significantly in the level of security and detecting weaknesses exposed<br />
by the sites allows the EGI security operations to contact the sites<br />
before the issue leads to an incident. Information produced by security<br />
monitoring is also important during assessment of new risks and<br />
vulnerabilities since it enables to identify the scope and impact of a<br />
potential security incident. The whole activity needs to be closely linked to other<br />
security-related tasks, namely the Incident Response Task Force and SVG<br />
and provide reliable and quick support to them (for instance to<br />
introduce new checks or process collected data). The task needs to<br />
cooperate with other activities responsible for general EGI monitoring<br />
and will need to coordinate their developments among these activities. Additional<br />
connections need to be maintained to the operations dashboard and<br />
common activities doing support to sites to make sure detected security issues<br />
are handled properly.<br />
<br />
Development/maintenance of security monitoring is described in the dedicated section on [[#Security Monitoring]].<br />
<br />
===Impact on funding ===<br />
It has already been acknowledged that some areas of security coordination are underfunded today in EGI-InSPIRE. Lack of global effort in the Incident Response Team is a growing problem and the amount of global effort to coordinate SVG (currently 1 PM/year) is way too small. We have therefore decided to give honest estimates of the amount of effort required to perform adequate global coordination of security in EGI. <br />
<br />
Experience over the last 2 years in EGI-InSPIRE has established that the amount of global coordination effort required to perform these critical duties is as follows.<br />
<br />
Person-Months per year, total effort: [partners to be assigned]<br />
<br />
*6+2 PM Security policy coordination and the support of its implementation<br />
*12 PM IRTF coordination and advanced incident response<br />
*6 PM SVG coordination<br />
*6 PM Security coordination through service challenges and training<br />
*4 PM Security monitoring coordination <br />
<br />
Total effort required 36 PM/year.<br />
<br />
== Service Level Management: availability/reliability reports==<br />
Partner: AUTH <br />
=== Current Status ===<br />
This task includes the validation of distribution of monthly availability statistics for Resource Centres, NGIs, EGI.eu, and the coordination of the evolution of the EGI OLA framework and the related reporting tools.<br />
<br />
===Foreseen evolution ===<br />
====Impact on funding ====<br />
<br />
=Infrastructure Services=<br />
<br />
==Software Rollout==<br />
Partner: LIP<br />
<br />
===Current status ===<br />
Updates of deployed software need to be gradually adopted in production after internal verification. This process is implemented in EGI through staged rollout, i.e. through the early deployment of a new component by a selected list of candidate Resource Centres. The successful verification of a new component is a precondition for declaring the software ready for deployment. Given the scale of the EGI infrastructure, this process requires careful coordination to ensure that every new capability is verified by a representative pool of candidate sites, to supervise the responsiveness of the candidate sites and ensure that the staged rollout progresses well without introducing unnecessary delays, and to review the reports produced. It also ensures the planning of resources according to the foreseen release schedules from the Technology Providers. EGI.eu coordination is necessary to ensure a successful interoperation of the various stakeholders: Resource Centres, Technology Providers, the EGI.eu Technical Manager and the EGI repository managers.<br />
<br />
This activities includes:<br />
* Definition and adoption of a workflow to automate software deployment <br />
* Coordination of the staged rollout activities carried out by the NGIs<br />
* Liaison with the UMD team (EGI-InSPIRE SA2)and the Products Teams<br />
<br />
===Foreseen evolution ===<br />
====Impact on funding ====<br />
<br />
== Monitoring ==<br />
=== Central SAM monitoring services===<br />
Partner: CERN <br />
====Current status====<br />
A distributed monitoring framework is necessary to continuously test the level of functionality delivered by each service node instance in the production Resource Centres, to generate alarms and tickets in case of critical failures and to compute monthly availability and reliability statistics, and to monitor and troubleshoot network problems. The Monitoring Infrastructure is a distributed service based on Nagios and messaging. The central services – operated by EGI.eu – include systems such as the MyEGI portal for the visualisation of information, and a set of databases for the persistent storage of information about test results, availability statistics, monitoring profiles and aggregated topology information. The central services need to interact with the local monitoring infrastructures operated by the NGIs. The central monitoring services are critical and need to deliver high availability.<br />
<br />
====Foreseen evolution ====<br />
=====Impact on funding =====<br />
<br />
<br />
=== Broker network=== <br />
Partner: GRNET (coord), SRCE, CERN <br />
====Current status====<br />
====Foreseen evolution ====<br />
=====Impact on funding =====<br />
<br />
<br />
== Accounting ==<br />
<br />
=== APEL central DB ===<br />
Partner: STFC<br />
<br />
====Current status====<br />
The EGI Accounting Infrastructure is distributed. At a central level it includes the repositories for the persistent storage of usage records. The Accounting Infrastructure is essential in a service-oriented business model to record usage information. Accounting data needs to be validated and regularly published centrally. The central databases are populated through individual usage records published by the Resource Centres, or through the publication of summarised usage records.<br />
<br />
===== Dependencies =====<br />
The Accounting Repository has a number of dependencies on other EGI tools:<br />
* Accounting Portal<br />
* GOCDB<br />
* EGI Message Brokers<br />
* GGUS<br />
* Operations Portal and Operations Dashboard<br />
<br />
====Foreseen evolution ====<br />
2013/2014 Technical Evolution: <br />
* Accounting’s evolution over the final year of EGI-InSPIRE will be to consolidate the new Accounting repository to receive records from the EMI APEL 3 client, from the regional APEL server implementations and from other CPU accounting sources (MAPPER, EDGI, UNICORE etc.). Additionally, the archived data in summary form will be migrated to the new format.<br />
* Other types of accounting (Cloud, Storage, Application etc.) is in early testing stage for the accounting repository, although the SSM publishing method has proved robust and usable in these new contexts. Next steps for the coming year are to test with multiple clients ensuring their representation of data is consistent from one client to another and producing summaries for the portal to publish.<br />
<br />
By the end of EGI-InSPIRE we will have implemented the new accounting system to receive and publish records from multiple clients, including a regional APEL server, and for multiple types of accounting.<br />
<br />
* Integration of accounting records from different types of accounting is the next step which would continue after EGI-InSPIRE if funding is available, as this is not yet in development. The implementation of storage accounting integrated with cloud accounting, for example, can only realistically be worked on once we have a body of data from the storage and cloud clients which may be related. Similarly for cloud/cpu and cloud/application integration. The feasibility of this integration requires some research which I envisage could not start until earliest Q3 2013 and would expect it to extend beyond EGI-InSPIRE. <br />
<br />
=====Impact on funding =====<br />
* Costs expected to stay constant up to April 2014 (aiming to address the developments set out in the first two bullets above and continue maintenance and support at the current level). <br />
* Current level of match funding from GridPP is expected until April 2014. <br />
* Reducing costs before April 2014 is unrealistic.<br />
* Current level of match funding from GridPP is expected until 2015.<br />
* Post-April 2013 - if there are additional development requirements then funding for these will be required, this would be for further developments in other types of accounting (Cloud, Storage, Application etc.). It is expected that requirements for these would evolve as their usage increases and this will require work beyond maintenance and operations. If the evolution of accounting is to include the integration of data from different types of accounting then this would also require further funding.<br />
<br />
=== Central accounting portal ===<br />
Partner: CESGA<br />
<br />
====Current status====<br />
The EGI accounting infrastructure is a complex system that involves various sensors in different <br />
regions, all publishing data to a central repository. The data is processed, summarized and displayed <br />
in the Accounting Portal, which acts as a common interface to the different accounting record <br />
providers and presents a homogeneous view of the data gathered and a user-friendly access to <br />
understanding resource utilisation.<br />
<br />
The current production version (v4.2 Fomalhaut) of the Accounting Portal is available at https://accounting.egi.eu. The regional Accounting Portal is ready, pending support from APEL regionalization.<br />
<br />
=====Dependencies=====<br />
The Accounting Portal has functional dependencies on the following tools: <br />
<br />
* GOCDB: List of sites and NGIs in production, list of available services in production. <br />
<br />
* CIC Portal: VOMS endpoints and VO list. <br />
<br />
* Accounting Repository: Accounting records and summarized accounting data.<br />
<br />
====Foreseen evolution ====<br />
In the period 2013/2014, the following directions are planned:<br />
* Contributed CPUs by site - Measuring the contribution in CPUs vs the number of hours, enhancing the reporting existing now with SPECInts.<br />
* Preliminar support for parallel (MPI) jobs - There were advances in this after the MPI vt lifespan, but further software development is needed.<br />
* New Accounting: Integration of all advances on Network, Storage and Application accounting on JRA1.4, apart from possible new developments that may arise.<br />
* EGI User usage accounting - Improvements on the userDN accounting.<br />
* Preliminar cloud support - Display and integration of the experimental sites offering cloud computing capabilities under the fedcloud task.<br />
* Regional portal codebase improvements - Implantation and improvement based on regional experiences if appropriate.<br />
* XML endpoints generalization and improvement - Implementation of a friendlier XML interface and documentation for users wishing programmatic access<br />
* Cloud support improvements - Further integration of cloud accounting characteristics.<br />
<br />
=====Impact on funding =====<br />
The funding should remain constant until February 2014. <br />
After February 2014 the status, dedication and funding of staff maintaining the portal is not clear. The availability of National and regional funding is also uncertain, perhaps the situation will be clearer next year.<br />
To ensure continued operation, the funding would have to be maintained at the current level<br />
<br />
== Security Monitoring ==<br />
* Security Nagios server. Partner: GRNET <br />
* CSIRT Pakiti. Partner CESNET <br />
<br />
===Current status ===<br />
The objective of a Security Infrastructure is to protect itself from intrusions such as exploitable software vulnerabilities, misuse by authorised users, resource "theft", etc., while allowing the information, resources and services to remain accessible and productive to its intended users. A specifically designed set of tools and services help reduce these vulnerabilities such as monitoring individual resource centers (based on Nagios and Pakiti), a central security dashboard to allow sites, NGIs and EGI Computer Security Incident Response Teams to access security alerts in a controlled manner, and a ticketing system to support coordination efforts.<br />
<br />
===Foreseen evolution ===<br />
====Impact on funding ====<br />
<br />
== Configuration Repository (GOCDB) ==<br />
Partner: STFC <br />
===Current status===<br />
EGI relies on a central database (GOCDB) to record static information about different entities such as the Operations Centres, the Resource Centres, and the service instances. It also provides contact, role and status information. GOCDB is a source of information for many other operational tools, such as the broadcast tool, the Aggregated Topology Provider, etc.<br />
<br />
===Foreseen evolution ===<br />
1yr Technical Evolution: <br />
GOCDB needs to evolve along the following themes to address current and emerging stakeholder requirements: <br />
* GOCDB v5 (~April/May). Replaces Oracle PROM database with ORM DB objects. Is needed to support different RDBMSs, improves performance and will simplify development. Requires changes to PI to be accepted by all PTs. See: https://wiki.egi.eu/wiki/Doctrine<br />
* Update current mutually-exclusive ‘EGI’ and ‘Local’ scope tags to be non-exclusive. Allows sites/services to be tagged multiple times with project-specific tags (e.g. ‘UK_NES’) and wider ‘EGI’ scope tags. Objects are created once. Maintains the integrity of topology information across different target infrastructures. PI ‘scope’ parameter value to support comma-separated list. Service scope values chosen from Site scope values. <br />
* Render GOCDB data in Glue2 XML and provide new PI method(s) to post downtimes using XML. Needed to address interoperability and data consistency across different info-systems/infrastructures. Has been requested by different stakeholders. <br />
<br />
====Impact on funding ====<br />
* Costs expected to stay constant up to April 2014 (aiming to address these developments and continue ops support at/around the current level). <br />
* Current level of match funding from GridPP is expected until April 2014. <br />
* Reducing costs before April 2014 is unrealistic. <br />
* Cost changes post April 2014 are hard to predict; depends on subsequent changes to requirements. Current level of match funding from GridPP is expected until 2015.<br />
<br />
== Operations Portal ==<br />
Partner: IN2P3<br />
===Current status===<br />
EGI.eu provides a central portal for the operations community that offers a bundle of different capabilities, such as the broadcast tool, VO management facilities, and a dashboard for grid operators that is used to display information about failing monitoring probes and to open tickets to the Resource Centres affected. The dashboard also supports the central grid oversight activities. It is fully interfaced with the EGI Helpdesk and the monitoring system through the message passing. It is a critical component as it is used by all EGI Operations Centres to provide support to the respective Resource Centres. <br />
<br />
=== Foreseen evolution ===<br />
<br />
<span style="line-height: 1.5em;">The Operations Portal is based on<br />
</span>lot of emerging technologies used in the Web development ( frameworks , Css templating system , javascript libraries ...) . <br />
<br />
The emergence of such technologies provide new opportunities to the users in terms of ergonomics , visualisation layer , services offer &nbsp;and bring also new usage and new possibliites of features. <br />
<br />
The Operations Portal team is following such evolutions and aiming&nbsp; at providing these opportunitites to the community if they are useful.<br> The portal has been designed in a modular way and as an aggregation plateform. The flexibility of the architecture allows for a&nbsp; huge&nbsp;number of data sources, and to provide standard access to information. <br />
<br />
The core of the data gathering system is the web service facility called Lavoisier. <br />
<br />
<span style="line-height: 1.5em;">Lavoisier’s<br />
</span>flexibility allows us to be ready to integrate almost any kind of new information if needed&nbsp;<span style="line-height: 1.5em;">and meaningful. For the new resource types coming into<br />
</span>the EGI production infrastructure, such as <br />
<br />
HPC systems, virtualized resources, desktop resources we are able&nbsp;to integrate its via plug-ins inside Lavoisier.<br> <br />
<br />
<br> <br />
<br />
==== Impact on funding ====<br />
<br />
<span style="line-height: 1.5em;">With the current level of<br />
</span>fundings (PY4) we can ensure the daily maintenance and we can provide only some improvements on the existing tool if developments are limited. <br />
<br />
<span style="line-height: 1.5em;">A decrease of funding after April 2014 will&nbsp; imply that </span><span style="line-height: 19.1875px;">additional development requirements<br />
</span>will not been taken into account and further developments to extend the current&nbsp;<span style="line-height: 19.1875px;">&nbsp;tool with new technologies and new source of<br />
</span>information will not be possible&nbsp; (HPC or cloud resources) . All new developments&nbsp; would also require new funding.<br><br />
<br />
== Metrics Portal ==<br />
Partner: CESGA <br />
===Current status===<br />
The Metrics Portal displays a set of metrics that will be used to monitor the performance of the <br />
infrastructure and the project, and to track their changes over time. The portal automatically collects <br />
all the required data and calculates these metrics before displaying them in the portal. The portal <br />
aggregates information from different sources such as GOCDB, GGUS, etc. <br />
<br />
The Metrics Portal has been used for the last year to gather metrics from the project tasks. Depending of changes on the structure and scope of the projects and its tasks and activities, the portal will be updated while keeping the old metrics in their validity periods. <br />
<br />
The Portal also monitorizes the evolution of the infrastructure month by month and it is the only way to have access to historic data on infrastructure evolution data (vs. realtime data).<br />
<br />
====Dependencies====<br />
The Metrics Portal has many dependencies. These include: <br />
<br />
* Accounting Portal: To display accounting metrics, most active VOs, Number of submitted jobs, etc. <br />
<br />
* BDII: Number of CPUs and Cores in production, online and nearline storage, mpi sites. <br />
<br />
* GGUS: Number of tickets created/closed. Tickets response times, Number of tickets created by priority, etc. <br />
<br />
* GOCDB: Sites in production, number of countries and NGIs in EGI. <br />
<br />
* ACE: Availability and reliability metrics. <br />
<br />
=== Foreseen evolution ===<br />
<br />
* Manual metrics expansion and refinement - In the line of having finer granularity and semantics to enable better user reporting.<br />
* Views enhancement and optimization - Crossbrowser integration, possibly AJAX functionality, mobile integration.<br />
* Regional portal codebase improvements - Refactoring, code documentation and quality improvement.<br />
* GGUS metrics improvement and new A/R metrics <br />
* Access Control improvements - Finer grained access mechanism.<br />
* New customized reports with Excel support <br />
<br />
=== Impact on funding ===<br />
The funding should remain constant until February 2014. After February 2014 the status, dedication and funding of staff maintaining the portal is not clear. The availability of National and regional funding is also uncertain, perhaps the situation will be clearer next year. To ensure continued operation, the funding would have to be maintained at the current level<br />
<br />
== Helpdesk ==<br />
Partner: KIT <br />
===Current status===<br />
EGI provides support to users and operators through a distributed helpdesk with central coordination (GGUS). The central helpdesk provides a single interface for support. The central system is interfaced to a variety of other ticketing systems at the NGI level in order to allow a bi-directional exchange of tickets (for example, those opened locally can be passed to the central instance or other areas, while user and operational problem tickets can be open centrally and subsequently routed to the NGI local support infrastructures).<br />
<br />
=== Foreseen evolution ===<br />
* GGUS Report Generator - Some fine tuning is still to be done. Another report [[https://rt.egi.eu/guest/Ticket/Display.html?id=4752 ETA accuracy]] needs implementation<br />
* VOMS synchronization - Restructuring VOMS synchronization for making it fail-safe.<br />
* GGUS Interfaces with other ticketing systems - Interfaces for PRACE/MAPPER, DANTE, NGI_IBERGRID<br />
* Alarm process for central operations tools - Implement alarm process for EGI central operations tools<br />
* Implementation of specific work flows for CSIRT/Security - The CSIRT team is currently evaluating whether they want to use GGUS. If CSIRT will use GGUS the permissions and access rights schema needs to be adapted to their needs.<br />
* Web portal - Introduce alternative authentication/authorization processes and provide specific view for CMS VO<br />
* Integration of operations portal in GGUS<br />
* Ticket monitoring in GGUS - Provide input on how processing tickets waiting for submitter's input and input on how processing tickets waiting for activity of technology providers after the end of EMI.<br />
<br />
<br><br />
<br />
=== Impact on funding ===<br />
<br />
<br><br />
<br />
== Core and Catch-all Services ==<br />
Parner: GRNET JRU<br />
<br />
===Current status===<br />
Auxiliary core services are needed for the good running of Infrastructure Services. Examples of such services are VOMS service and VO membership management for infrastructural VOs (DTEAM, OPS), the provisioning of middleware services needed by the monitoring infrastructure (e.g. top-BDII and WMS), the catch-all CA and other catch-all core services to support small user communities (central catalogues, workflow schedulers, authentication services).<br />
<br />
===Foreseen evolution ===<br />
This should include central SAM instances for ad-hoc monitoring objectives (like the middleware monitoring SAM).<br />
<br />
====Impact on funding ====<br />
<br />
= Resources =<br />
* Deliverable [https://documents.egi.eu/document/1471 D4.7]: Operations sustainability <br />
* [https://documents.egi.eu/document/1098 Seeking new horizons: EGI's role in 2020]<br />
* IMPORTANT. [https://wiki.egi.eu/wiki/File:EGIActionPlanV1.pdf | EGI Community Action Plan 2013 and beyond], EGI Council, Dec 2012</div>Kourilhttps://wiki.egi.eu/w/index.php?title=EGI-InSPIRE:SA1_EGI_Global_tasks_evolution&diff=50320EGI-InSPIRE:SA1 EGI Global tasks evolution2013-01-25T09:53:16Z<p>Kouril: /* Security Monitoring Coordination */</p>
<hr />
<div>[[Category:EGI-inSPIRE SA1]]<br />
This document provided by the partners responsible of EGI operations global tasks provide information about current status and the envisaged evolution of these tasks '''after April 2014'''.<br />
<br />
=Human Services=<br />
==Operation Management Board Coordination==<br />
Partner: EGI.eu<br />
===Current status===<br />
The Operations Management Board (OMB) drives future developments in the operations area by making sure that the infrastructure delivers high availability, is secure, meets the demand of existing user communities and that infrastructure operations evolve to support the integration of new resource infrastructures. It does this by providing management and developing policies and procedures for the operational services that are integrated into the production infrastructure.<br />
The OMB is responsible of technical roadmapping and of the definition and execution of processes for periodic gathering of requirements.<br />
<br />
===Foreseen evolution ===<br />
<br />
====Impact on funding ====<br />
<br />
==Software Support ==<br />
<br />
===Current status===<br />
EGI.eu provides first and second level user and operations support and this function includes the following tasks:<br />
* function coordination (partner: CESNET)<br />
* ticket triage and assignment for dispatching of tickets to the appropriate SUs within GGUS (partners: INFN, CESNET)<br />
* 1st and 2nd level software support, encompassing both grid middleware and operational tools (operational tickets are dispatched to NGI operations SUs, so are not internally addressed by the software support team). This includes the production of howtos and reporting to operations meetings about critical incidents (partners: CESNET, INFN, JUELICH, LIU and STFC<br />
* Ticket oversight and follow-up (partner: KIT): this function includes administrative and reporting functions of the helpdesk infrastructure (e.g. collecting ticket statistics, internal and external reporting of statistics for SLAs monitoring and other reporting duties), and follow-up (notifying supporters when the reaction to high-priority tickets is not fast enough, requesting information from ticket submitters when they do not react, ensuring assigners/resolvers will react sufficiently fast when the submitter provides additional information).<br />
<br />
[https://documents.egi.eu/document/1104| More information about this task]<br />
<br />
===Foreseen evolution ===<br />
<br />
<br />
====Impact on funding ====<br />
<br />
=== Coordination of Grid Oversight ===<br />
Partners: SARA, CYFRONET<br />
<br />
===Current status===<br />
Grid Oversight is an activity aimed at controlling the infrastructure and solving arising operational issues. Theses issues can be of different complexity and importance, and may be caused by various reasons on regional or central level. For the scalability reasons the Grid Oversight has hierarchical structure: teams on regional (ROD) and central (COD) level contribute to it, solving problems within their scope. The COD part of the function is a global task.<br />
Speaking in ITSM terms the processes in which COD is naturally interested in are these of Service<br />
Operations area, especially Incident Management and Problem Management. The oversight of Incident<br />
Management is organized in an escalation process and COD is the body to which incidents that can not<br />
be handled on regional level are escalated.<br />
<br />
===Foreseen evolution ===<br />
After april 2014, there will be more emphasis on supporting NGIs, assistance of user communities with respect to resource allocation. This will be in addition to what is already being done today.<br />
* Read the [https://documents.egi.eu/document/1529 full proposal]<br />
<br />
====Impact on funding ====<br />
This is uncertain.<br />
<br />
== Coordination of network support, monitoring, troubleshooting ==<br />
Partner: GARR<br />
<br />
===Current status===<br />
Provides network support for the resolution of end-to-end network performance issues.<br />
EGI is a highly distributed networked infrastructure of grid services using network connectivity for remote job submission, data transfer and data access, hence tools are needed for network troubleshooting and performance monitoring<br />
<br />
===Foreseen evolution ===<br />
<br />
====Impact on funding ====<br />
<br />
== Coordination of Operational interoperation between NGIs and DCIs ==<br />
Partner: EGI.eu<br />
<br />
===Current status===<br />
EGI coordinates the integration of heterogeneous middleware stacks and Distributed Computing Infrastructures with the EGI operational infrastructures such as: accounting, monitoring, managemenet and support.<br />
<br />
===Foreseen evolution ===<br />
<br />
====Impact on funding ====<br />
<br />
== Coordination of documentation==<br />
Partner: EGI.eu<br />
<br />
===Current status===<br />
Coordination of maintenance and development operational documentation, procedures, best practices.<br />
<br />
===Foreseen evolution ===<br />
====Impact on funding ====<br />
<br />
== Security Operations Coordination ==<br />
Partners: STFC, NIKHEF<br />
<br />
(now including security policy coordination as this is closely related to operations)<br />
<br />
===Current status===<br />
<!-- add and modify text as needed. This paragraph should include: EGI CSIRT, security training, security drills, IRTF, SVG and if you want SPG --><br />
The inherent value of the e-Infrastructure provides a strong rationale for security coordination amongst the EGI participants at various levels. Central coordination of the security activities ensures that policies, operational security, and maintenance are compatible amongst all partners, improving availability and lowering access barriers for use of the infrastructure. Today, the Security Policy Group (SPG) coordinates a consistent set of security policies, developed in collaboration with all interested NGIs, and provides technical implementations of these policies for simplified use by the NGIs where relevant. In addition, security and incident response is provided through the EGI Computer Security and Incident Response Team (CSIRT) by coordinating activity in the NGIs and at the sites across the infrastructure. This coordination ensures that incidents are promptly and efficiently handled, that common policies are followed by providing services such as security monitoring, and by training and dissemination with the goal of improving the response to incidents. The overall incident response capabilities of the sites, also with respect to new technologies introduced by the user communities (VOs), such as the VO-Job-submission frameworks, are frequently assessed through the EGI-wide security drills.<br />
<br />
===Foreseen evolution ===<br />
Security is an ongoing process. Policies, procedures, operations, technology and trust have to constantly evolve to address new threats and risks. In the security threat risk assessment carried out in 2012 one of the threats highlighted as a high risk issue was “The move to more use of Cloud technologies may lead to security problems”. There is no doubt that there will be many issues to be solved in the provision of secure operations as we deploy new technologies, which we are sure will require at least the current level of effort to manage and co-ordinate. We have decided to request the effort we will need for global coordination of security for EGI, based on what we are currently doing and the foreseen future needs. We are convinced that we will continue to need at least this level of effort and that this will need to be funded somehow.<br />
<br />
Experience of providing such security coordination over the last two years has shown that this includes multiple aspects that can be more clearly distinguished when evolving the task for the future, as presented in the following sub-sections.<br />
<br />
====Security Policy Coordination and the support of its implementation====<br />
Security policy development covers diverse aspects, including operational<br />
policies (agreements on vulnerability management, intrusion detection and<br />
prevention, regulation of access, and enforcement), incident response policies<br />
(governing the exchange of information and expected actions), participant<br />
responsibilities (including acceptable use policies, identifying users and<br />
managing user communities), traceability, legal aspects, and the protection<br />
of personal data. In an environment without central control, such as EGI,<br />
common identity management such as provided by the IGTF, is needed to ensure<br />
unique and persistent assignments of rights and privileges. Since research is<br />
global, such policies must be coordinated with peer infrastructures in Europe<br />
and elsewhere, such as PRACE-RI, Open Science Grid, XSEDE, and like efforts in<br />
the Asia Pacific. Coordination mechanisms such as the FIM4R group, TERENA<br />
REFEDS, SCI, Open Grid Forum and the IGTF are employed.<br />
For some elements of these policies (such as the common identity management)<br />
having a central reference implementation for immediate re-use by the NGIs<br />
saves on total effort needed in the long run. The use today of the centrally<br />
produced "EGI trust anchor distribution" is expected to continue.<br />
<br />
====Incident Response Task Force (IRTF) coordination and advanced incident response====<br />
Experience has shown that the complexity of multi-domain incidents at the<br />
scale of EGI necessitates dedicated experts in incident response and forensics<br />
to deal with global incidents and to provide support to EGI participants to<br />
address localised incidents before they spread across EGI. Experience with the<br />
rotational scheme used today in EGI has shown that it is<br />
very hard to retain unique expertise in a widely distributed community with<br />
high personnel turn-over. In practice, incident response is provided by a<br />
dedicated core team, with specialist forensics support concentrated in just a<br />
few individuals. It is essential that this expertise is available as and when<br />
needed, but it cannot provide global coverage for any EGI site. <br />
We propose to establish a small core team which holds the coordination<br />
role and provides advanced support in incident response and forensics.<br />
The primary responsibility for basic incident response and forensics<br />
will still lie with each NGI, while the EGI Global IRTF will coordinate<br />
incident response and information exchange. However, for complex<br />
multi-site incidents and in cases where advanced forensics is needed,<br />
the EGI Global IRTF will step in and take an active part, to protect the<br />
continued integrity of the EGI infrastructure as a whole. Investment in<br />
a relatively small amount of global coordination effort, removes the<br />
need for each NGI to have to maintain its own specialist IT security<br />
capability and has the potential to realise cost savings within each NGI.<br />
<br />
====Software Vulnerability (SVG) coordination====<br />
The Software Vulnerability Group (SVG) aims at eliminating existing vulnerabilities from the deployed infrastructure, primarily from the grid middleware, and avoiding the introduction of new ones, thus preventing security incidents. This activity will need to continue both to handle new vulnerabilities found in the Grid middleware currently deployed, and to handle vulnerabilities in software used by future technology to facilitate the sharing of distributed resources such as federated clouds. The SVG handles vulnerabilities reported in software used specifically in the EGI infrastructure. This depends on investigation and risk assessment by a collaborative team drawn from technology providers and other security groups, known as the Risk Assessment Team or 'RAT'. Considering the recent number of vulnerabilities detected and the co-ordination effort needed with other entities (Technology providers, EGI software distribution managers and coordinators, and central operations co-ordination) this task needs explicit recognition and assignment of dedicated effort. In particular the SVG also has a role in determining the threat posed by software deployed in the infrastructure independent of specific vulnerability events. SVG also has a role in the co-ordination and prioritization of 'Vulnerability Assessment' work, which is the examination of software to find whether any vulnerabilities exist. The SVG has also been asked to assess or advise on the assessment of other pieces of software prior to recommending their deployment on the EGI infrastructure, but has insufficient manpower to carry this out. <br />
<br />
====Security Coordination through Security Service Challenges and Training====<br />
Participating in a global infrastructure is still not a very common task for<br />
some resource centres. Unless specific efforts are made to ensure communication on<br />
incidents is effective between all EGI participants, the 'weakest link'<br />
principle applies and the integrity of the entire infrastructure can<br />
inadvertently be put at risk by a single user or resource. The use of<br />
'security drills', exercising the incident response communications channels,<br />
has proven particularly effective in ensuring open and effective exchange of<br />
information. Additionally, these security drills can be re-used at a site or<br />
national level, where they serve as trainings in computer security forensics<br />
and identification of intrusion and threats.<br />
To be effective, the security drills must be realistic, current with respect<br />
to the software and intrusion vectors used to exercise the site, and be based<br />
on the actual communication infrastructure of EGI. The drills need development<br />
(mainly contributed) and periodic use in realistic tests (the coordination<br />
function included here). Re-using the security drills for training and<br />
national (re)use needs limited 'train the trainer' effort which is best<br />
provided for centrally.<br />
<br />
====Security Monitoring Coordination====<br />
EGI is an interconnected federation where a single vulnerable place may<br />
have a huge impact on the whole infrastructure. In order to recognize<br />
the risks and to address potential vulnerabilities in a timely manner,<br />
the EGI Security Monitoring provides an oversight of the infrastructure<br />
from the security standpoint. Also, sites connected to EGI differ<br />
significantly in the level of security and detecting weaknesses exposed<br />
by the sites allows the EGI security operations to contact the sites<br />
before the issue leads to an incident. Information produced by security<br />
monitoring is also important during assessment of new risks and<br />
vulnerabilities since it enables to identify the scope and impact of a<br />
potential security incident. The whole activity needs to be closely linked to other<br />
security-related tasks, namely the Incident Response Task Force and SVG<br />
and provide reliable and quick support to them (for instance to<br />
introduce new checks or process collected data). The task needs to<br />
cooperate with other activities responsible for general EGI monitoring<br />
and will need to coordinate their developments among these activities. Additional<br />
connections need to be maintained to the operations dashboard and<br />
common activities doing support to sites to make sure detected security issues<br />
are handled properly.<br />
<br />
[Development/maintenance of security monitoring is described in the dedicated section on security monitoring]<br />
<br />
===Impact on funding ===<br />
It has already been acknowledged that some areas of security coordination are underfunded today in EGI-InSPIRE. Lack of global effort in the Incident Response Team is a growing problem and the amount of global effort to coordinate SVG (currently 1 PM/year) is way too small. We have therefore decided to give honest estimates of the amount of effort required to perform adequate global coordination of security in EGI. <br />
<br />
Experience over the last 2 years in EGI-InSPIRE has established that the amount of global coordination effort required to perform these critical duties is as follows.<br />
<br />
Person-Months per year, total effort: [partners to be assigned]<br />
<br />
*6+2 PM Security policy coordination and the support of its implementation<br />
*12 PM IRTF coordination and advanced incident response<br />
*6 PM SVG coordination<br />
*6 PM Security coordination through service challenges and training<br />
*4 PM Security monitoring coordination <br />
<br />
Total effort required 36 PM/year.<br />
<br />
== Service Level Management: availability/reliability reports==<br />
Partner: AUTH <br />
=== Current Status ===<br />
This task includes the validation of distribution of monthly availability statistics for Resource Centres, NGIs, EGI.eu, and the coordination of the evolution of the EGI OLA framework and the related reporting tools.<br />
<br />
===Foreseen evolution ===<br />
====Impact on funding ====<br />
<br />
=Infrastructure Services=<br />
<br />
==Software Rollout==<br />
Partner: LIP<br />
<br />
===Current status ===<br />
Updates of deployed software need to be gradually adopted in production after internal verification. This process is implemented in EGI through staged rollout, i.e. through the early deployment of a new component by a selected list of candidate Resource Centres. The successful verification of a new component is a precondition for declaring the software ready for deployment. Given the scale of the EGI infrastructure, this process requires careful coordination to ensure that every new capability is verified by a representative pool of candidate sites, to supervise the responsiveness of the candidate sites and ensure that the staged rollout progresses well without introducing unnecessary delays, and to review the reports produced. It also ensures the planning of resources according to the foreseen release schedules from the Technology Providers. EGI.eu coordination is necessary to ensure a successful interoperation of the various stakeholders: Resource Centres, Technology Providers, the EGI.eu Technical Manager and the EGI repository managers.<br />
<br />
This activities includes:<br />
* Definition and adoption of a workflow to automate software deployment <br />
* Coordination of the staged rollout activities carried out by the NGIs<br />
* Liaison with the UMD team (EGI-InSPIRE SA2)and the Products Teams<br />
<br />
===Foreseen evolution ===<br />
====Impact on funding ====<br />
<br />
== Monitoring ==<br />
=== Central SAM monitoring services===<br />
Partner: CERN <br />
====Current status====<br />
A distributed monitoring framework is necessary to continuously test the level of functionality delivered by each service node instance in the production Resource Centres, to generate alarms and tickets in case of critical failures and to compute monthly availability and reliability statistics, and to monitor and troubleshoot network problems. The Monitoring Infrastructure is a distributed service based on Nagios and messaging. The central services – operated by EGI.eu – include systems such as the MyEGI portal for the visualisation of information, and a set of databases for the persistent storage of information about test results, availability statistics, monitoring profiles and aggregated topology information. The central services need to interact with the local monitoring infrastructures operated by the NGIs. The central monitoring services are critical and need to deliver high availability.<br />
<br />
====Foreseen evolution ====<br />
=====Impact on funding =====<br />
<br />
<br />
=== Broker network=== <br />
Partner: GRNET (coord), SRCE, CERN <br />
====Current status====<br />
====Foreseen evolution ====<br />
=====Impact on funding =====<br />
<br />
<br />
== Accounting ==<br />
<br />
=== APEL central DB ===<br />
Partner: STFC<br />
<br />
====Current status====<br />
The EGI Accounting Infrastructure is distributed. At a central level it includes the repositories for the persistent storage of usage records. The Accounting Infrastructure is essential in a service-oriented business model to record usage information. Accounting data needs to be validated and regularly published centrally. The central databases are populated through individual usage records published by the Resource Centres, or through the publication of summarised usage records.<br />
<br />
===== Dependencies =====<br />
The Accounting Repository has a number of dependencies on other EGI tools:<br />
* Accounting Portal<br />
* GOCDB<br />
* EGI Message Brokers<br />
* GGUS<br />
* Operations Portal and Operations Dashboard<br />
<br />
====Foreseen evolution ====<br />
2013/2014 Technical Evolution: <br />
* Accounting’s evolution over the final year of EGI-InSPIRE will be to consolidate the new Accounting repository to receive records from the EMI APEL 3 client, from the regional APEL server implementations and from other CPU accounting sources (MAPPER, EDGI, UNICORE etc.). Additionally, the archived data in summary form will be migrated to the new format.<br />
* Other types of accounting (Cloud, Storage, Application etc.) is in early testing stage for the accounting repository, although the SSM publishing method has proved robust and usable in these new contexts. Next steps for the coming year are to test with multiple clients ensuring their representation of data is consistent from one client to another and producing summaries for the portal to publish.<br />
<br />
By the end of EGI-InSPIRE we will have implemented the new accounting system to receive and publish records from multiple clients, including a regional APEL server, and for multiple types of accounting.<br />
<br />
* Integration of accounting records from different types of accounting is the next step which would continue after EGI-InSPIRE if funding is available, as this is not yet in development. The implementation of storage accounting integrated with cloud accounting, for example, can only realistically be worked on once we have a body of data from the storage and cloud clients which may be related. Similarly for cloud/cpu and cloud/application integration. The feasibility of this integration requires some research which I envisage could not start until earliest Q3 2013 and would expect it to extend beyond EGI-InSPIRE. <br />
<br />
=====Impact on funding =====<br />
* Costs expected to stay constant up to April 2014 (aiming to address the developments set out in the first two bullets above and continue maintenance and support at the current level). <br />
* Current level of match funding from GridPP is expected until April 2014. <br />
* Reducing costs before April 2014 is unrealistic.<br />
* Current level of match funding from GridPP is expected until 2015.<br />
* Post-April 2013 - if there are additional development requirements then funding for these will be required, this would be for further developments in other types of accounting (Cloud, Storage, Application etc.). It is expected that requirements for these would evolve as their usage increases and this will require work beyond maintenance and operations. If the evolution of accounting is to include the integration of data from different types of accounting then this would also require further funding.<br />
<br />
=== Central accounting portal ===<br />
Partner: CESGA<br />
<br />
====Current status====<br />
The EGI accounting infrastructure is a complex system that involves various sensors in different <br />
regions, all publishing data to a central repository. The data is processed, summarized and displayed <br />
in the Accounting Portal, which acts as a common interface to the different accounting record <br />
providers and presents a homogeneous view of the data gathered and a user-friendly access to <br />
understanding resource utilisation.<br />
<br />
The current production version (v4.2 Fomalhaut) of the Accounting Portal is available at https://accounting.egi.eu. The regional Accounting Portal is ready, pending support from APEL regionalization.<br />
<br />
=====Dependencies=====<br />
The Accounting Portal has functional dependencies on the following tools: <br />
<br />
* GOCDB: List of sites and NGIs in production, list of available services in production. <br />
<br />
* CIC Portal: VOMS endpoints and VO list. <br />
<br />
* Accounting Repository: Accounting records and summarized accounting data.<br />
<br />
====Foreseen evolution ====<br />
In the period 2013/2014, the following directions are planned:<br />
* Contributed CPUs by site - Measuring the contribution in CPUs vs the number of hours, enhancing the reporting existing now with SPECInts.<br />
* Preliminar support for parallel (MPI) jobs - There were advances in this after the MPI vt lifespan, but further software development is needed.<br />
* New Accounting: Integration of all advances on Network, Storage and Application accounting on JRA1.4, apart from possible new developments that may arise.<br />
* EGI User usage accounting - Improvements on the userDN accounting.<br />
* Preliminar cloud support - Display and integration of the experimental sites offering cloud computing capabilities under the fedcloud task.<br />
* Regional portal codebase improvements - Implantation and improvement based on regional experiences if appropriate.<br />
* XML endpoints generalization and improvement - Implementation of a friendlier XML interface and documentation for users wishing programmatic access<br />
* Cloud support improvements - Further integration of cloud accounting characteristics.<br />
<br />
=====Impact on funding =====<br />
The funding should remain constant until February 2014. <br />
After February 2014 the status, dedication and funding of staff maintaining the portal is not clear. The availability of National and regional funding is also uncertain, perhaps the situation will be clearer next year.<br />
To ensure continued operation, the funding would have to be maintained at the current level<br />
<br />
== Security Monitoring ==<br />
* Security Nagios server. Partner: GRNET <br />
* CSIRT Pakiti. Partner CESNET <br />
<br />
===Current status ===<br />
The objective of a Security Infrastructure is to protect itself from intrusions such as exploitable software vulnerabilities, misuse by authorised users, resource "theft", etc., while allowing the information, resources and services to remain accessible and productive to its intended users. A specifically designed set of tools and services help reduce these vulnerabilities such as monitoring individual resource centers (based on Nagios and Pakiti), a central security dashboard to allow sites, NGIs and EGI Computer Security Incident Response Teams to access security alerts in a controlled manner, and a ticketing system to support coordination efforts.<br />
<br />
===Foreseen evolution ===<br />
====Impact on funding ====<br />
<br />
== Configuration Repository (GOCDB) ==<br />
Partner: STFC <br />
===Current status===<br />
EGI relies on a central database (GOCDB) to record static information about different entities such as the Operations Centres, the Resource Centres, and the service instances. It also provides contact, role and status information. GOCDB is a source of information for many other operational tools, such as the broadcast tool, the Aggregated Topology Provider, etc.<br />
<br />
===Foreseen evolution ===<br />
1yr Technical Evolution: <br />
GOCDB needs to evolve along the following themes to address current and emerging stakeholder requirements: <br />
* GOCDB v5 (~April/May). Replaces Oracle PROM database with ORM DB objects. Is needed to support different RDBMSs, improves performance and will simplify development. Requires changes to PI to be accepted by all PTs. See: https://wiki.egi.eu/wiki/Doctrine<br />
* Update current mutually-exclusive ‘EGI’ and ‘Local’ scope tags to be non-exclusive. Allows sites/services to be tagged multiple times with project-specific tags (e.g. ‘UK_NES’) and wider ‘EGI’ scope tags. Objects are created once. Maintains the integrity of topology information across different target infrastructures. PI ‘scope’ parameter value to support comma-separated list. Service scope values chosen from Site scope values. <br />
* Render GOCDB data in Glue2 XML and provide new PI method(s) to post downtimes using XML. Needed to address interoperability and data consistency across different info-systems/infrastructures. Has been requested by different stakeholders. <br />
<br />
====Impact on funding ====<br />
* Costs expected to stay constant up to April 2014 (aiming to address these developments and continue ops support at/around the current level). <br />
* Current level of match funding from GridPP is expected until April 2014. <br />
* Reducing costs before April 2014 is unrealistic. <br />
* Cost changes post April 2014 are hard to predict; depends on subsequent changes to requirements. Current level of match funding from GridPP is expected until 2015.<br />
<br />
== Operations Portal ==<br />
Partner: IN2P3<br />
===Current status===<br />
EGI.eu provides a central portal for the operations community that offers a bundle of different capabilities, such as the broadcast tool, VO management facilities, and a dashboard for grid operators that is used to display information about failing monitoring probes and to open tickets to the Resource Centres affected. The dashboard also supports the central grid oversight activities. It is fully interfaced with the EGI Helpdesk and the monitoring system through the message passing. It is a critical component as it is used by all EGI Operations Centres to provide support to the respective Resource Centres. <br />
<br />
=== Foreseen evolution ===<br />
<br />
<span style="line-height: 1.5em;">The Operations Portal is based on<br />
</span>lot of emerging technologies used in the Web development ( frameworks , Css templating system , javascript libraries ...) . <br />
<br />
The emergence of such technologies provide new opportunities to the users in terms of ergonomics , visualisation layer , services offer &nbsp;and bring also new usage and new possibliites of features. <br />
<br />
The Operations Portal team is following such evolutions and aiming&nbsp; at providing these opportunitites to the community if they are useful.<br> The portal has been designed in a modular way and as an aggregation plateform. The flexibility of the architecture allows for a&nbsp; huge&nbsp;number of data sources, and to provide standard access to information. <br />
<br />
The core of the data gathering system is the web service facility called Lavoisier. <br />
<br />
<span style="line-height: 1.5em;">Lavoisier’s<br />
</span>flexibility allows us to be ready to integrate almost any kind of new information if needed&nbsp;<span style="line-height: 1.5em;">and meaningful. For the new resource types coming into<br />
</span>the EGI production infrastructure, such as <br />
<br />
HPC systems, virtualized resources, desktop resources we are able&nbsp;to integrate its via plug-ins inside Lavoisier.<br> <br />
<br />
<br> <br />
<br />
==== Impact on funding ====<br />
<br />
<span style="line-height: 1.5em;">With the current level of<br />
</span>fundings (PY4) we can ensure the daily maintenance and we can provide only some improvements on the existing tool if developments are limited. <br />
<br />
<span style="line-height: 1.5em;">A decrease of funding after April 2014 will&nbsp; imply that </span><span style="line-height: 19.1875px;">additional development requirements<br />
</span>will not been taken into account and further developments to extend the current&nbsp;<span style="line-height: 19.1875px;">&nbsp;tool with new technologies and new source of<br />
</span>information will not be possible&nbsp; (HPC or cloud resources) . All new developments&nbsp; would also require new funding.<br><br />
<br />
== Metrics Portal ==<br />
Partner: CESGA <br />
===Current status===<br />
The Metrics Portal displays a set of metrics that will be used to monitor the performance of the <br />
infrastructure and the project, and to track their changes over time. The portal automatically collects <br />
all the required data and calculates these metrics before displaying them in the portal. The portal <br />
aggregates information from different sources such as GOCDB, GGUS, etc. <br />
<br />
The Metrics Portal has been used for the last year to gather metrics from the project tasks. Depending of changes on the structure and scope of the projects and its tasks and activities, the portal will be updated while keeping the old metrics in their validity periods. <br />
<br />
The Portal also monitorizes the evolution of the infrastructure month by month and it is the only way to have access to historic data on infrastructure evolution data (vs. realtime data).<br />
<br />
====Dependencies====<br />
The Metrics Portal has many dependencies. These include: <br />
<br />
* Accounting Portal: To display accounting metrics, most active VOs, Number of submitted jobs, etc. <br />
<br />
* BDII: Number of CPUs and Cores in production, online and nearline storage, mpi sites. <br />
<br />
* GGUS: Number of tickets created/closed. Tickets response times, Number of tickets created by priority, etc. <br />
<br />
* GOCDB: Sites in production, number of countries and NGIs in EGI. <br />
<br />
* ACE: Availability and reliability metrics. <br />
<br />
=== Foreseen evolution ===<br />
<br />
* Manual metrics expansion and refinement - In the line of having finer granularity and semantics to enable better user reporting.<br />
* Views enhancement and optimization - Crossbrowser integration, possibly AJAX functionality, mobile integration.<br />
* Regional portal codebase improvements - Refactoring, code documentation and quality improvement.<br />
* GGUS metrics improvement and new A/R metrics <br />
* Access Control improvements - Finer grained access mechanism.<br />
* New customized reports with Excel support <br />
<br />
=== Impact on funding ===<br />
The funding should remain constant until February 2014. After February 2014 the status, dedication and funding of staff maintaining the portal is not clear. The availability of National and regional funding is also uncertain, perhaps the situation will be clearer next year. To ensure continued operation, the funding would have to be maintained at the current level<br />
<br />
== Helpdesk ==<br />
Partner: KIT <br />
===Current status===<br />
EGI provides support to users and operators through a distributed helpdesk with central coordination (GGUS). The central helpdesk provides a single interface for support. The central system is interfaced to a variety of other ticketing systems at the NGI level in order to allow a bi-directional exchange of tickets (for example, those opened locally can be passed to the central instance or other areas, while user and operational problem tickets can be open centrally and subsequently routed to the NGI local support infrastructures).<br />
<br />
=== Foreseen evolution ===<br />
* GGUS Report Generator - Some fine tuning is still to be done. Another report [[https://rt.egi.eu/guest/Ticket/Display.html?id=4752 ETA accuracy]] needs implementation<br />
* VOMS synchronization - Restructuring VOMS synchronization for making it fail-safe.<br />
* GGUS Interfaces with other ticketing systems - Interfaces for PRACE/MAPPER, DANTE, NGI_IBERGRID<br />
* Alarm process for central operations tools - Implement alarm process for EGI central operations tools<br />
* Implementation of specific work flows for CSIRT/Security - The CSIRT team is currently evaluating whether they want to use GGUS. If CSIRT will use GGUS the permissions and access rights schema needs to be adapted to their needs.<br />
* Web portal - Introduce alternative authentication/authorization processes and provide specific view for CMS VO<br />
* Integration of operations portal in GGUS<br />
* Ticket monitoring in GGUS - Provide input on how processing tickets waiting for submitter's input and input on how processing tickets waiting for activity of technology providers after the end of EMI.<br />
<br />
<br><br />
<br />
=== Impact on funding ===<br />
<br />
<br><br />
<br />
== Core and Catch-all Services ==<br />
Parner: GRNET JRU<br />
<br />
===Current status===<br />
Auxiliary core services are needed for the good running of Infrastructure Services. Examples of such services are VOMS service and VO membership management for infrastructural VOs (DTEAM, OPS), the provisioning of middleware services needed by the monitoring infrastructure (e.g. top-BDII and WMS), the catch-all CA and other catch-all core services to support small user communities (central catalogues, workflow schedulers, authentication services).<br />
<br />
===Foreseen evolution ===<br />
This should include central SAM instances for ad-hoc monitoring objectives (like the middleware monitoring SAM).<br />
<br />
====Impact on funding ====<br />
<br />
= Resources =<br />
* Deliverable [https://documents.egi.eu/document/1471 D4.7]: Operations sustainability <br />
* [https://documents.egi.eu/document/1098 Seeking new horizons: EGI's role in 2020]<br />
* IMPORTANT. [https://wiki.egi.eu/wiki/File:EGIActionPlanV1.pdf | EGI Community Action Plan 2013 and beyond], EGI Council, Dec 2012</div>Kourilhttps://wiki.egi.eu/w/index.php?title=MW_SAM_tests&diff=41400MW SAM tests2012-10-10T10:53:05Z<p>Kouril: </p>
<hr />
<div>'''Table describes list of tests used for tracking installed MW versions on EGI sites. All tests are executed every 24h.'''<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" align="left"<br />
|-<br />
! Nagios test <br />
! Description<br />
|-<br />
| align="center" | eu.egi.sec.Classic-SE<br />
| Test is associated to Classic-CE service endpoints in the GOC DB and it always returns CRITICAL. This service type [[GOCDB/Input_System_User_Documentation#Service_types|has been obsoleted]] for a while and it should be removed from all sites.<br />
|-<br />
| align="center" | eu.egi.sec.CREAMCE-gLite-32<br />
| Test queries site BDII for the following pattern "(&(GlueServiceType=org.glite.ce.CREAM)(GlueServiceVersion=1.12.*)(GlueServiceEndpoint=*$HOSTNAME$*))". Returns CRITICAL if query returns any results.<br />
|-<br />
| align="center" | eu.egi.sec.gLite-CE<br />
| Test is associated to gLite-CE service endpoints in the GOC DB and it always returns CRITICAL. This service type [[GOCDB/Input_System_User_Documentation#Service_types|has been obsoleted]] for a while and it should be removed from all sites.<br />
|-<br />
| align="center" | eu.egi.sec.gLite-31<br />
| Test queries site BDII for the following pattern "(&(GlueServiceDataValue=3.1.0)(GlueChunkKey=*$HOSTNAME$*))". Returns CRITICAL if query returns any results.<br />
|-<br />
| align="center" | eu.egi.sec.gLite-32<br />
| Test queries site BDII for the following pattern "(&(GlueServiceDataValue=3.2.0)(GlueChunkKey=*$HOSTNAME$*))". Returns CRITICAL if query returns any results.<br />
|-<br />
| align="center" | eu.egi.sec.gLite-32-sup<br />
| Test queries site BDII for the following pattern "(&(GlueServiceDataValue=3.2.0)(GlueChunkKey=*$HOSTNAME$*))". Returns WARNING if query returns any results. This query is used for gLite 3.2 service types which are supported til the end of November 2012 (see the [http://glite.cern.ch/support_calendar/ gLite 3.2 support calendar]).<br />
|-<br />
| align="center" | eu.egi.sec.LCG-CE<br />
| Test is associated to CE service endpoints in the GOC DB and it always returns CRITICAL. LCG-CE is unsupported (see the [http://glite.cern.ch/support_calendar/ gLite 3.2 support calendar]).<br />
|-<br />
| align="center" | eu.egi.sec.MON<br />
| Test is associated to MON service endpoints in the GOC DB and it always returns CRITICAL. This service type [[GOCDB/Input_System_User_Documentation#Service_types|has been obsoleted]] for a while and it should be removed from all sites.<br />
|-<br />
| align="center" | eu.egi.sec.RB<br />
| Test is associated to RB service endpoints in the GOC DB and it always returns CRITICAL. This service type [[GOCDB/Input_System_User_Documentation#Service_types|has been obsoleted]] for a while and it should be removed from all sites.<br />
|-<br />
| align="center" | eu.egi.sec.Total-gLite-31<br />
| Test queries site BDII for the following pattern "(GlueServiceDataValue=3.1.0)". Returns CRITICAL if query returns any results. At this point query does not create alarm in Dashboard and it is used only as a counter of service endpoint with gLite 3.1 available on site.<br />
|-<br />
| align="center" | eu.egi.sec.Total-gLite-32<br />
| Test queries site BDII for the following pattern "(GlueServiceDataValue=3.2.0)". Returns WARNING if query returns any results. At this point query does not create alarm in Dashboard and it is used only as a counter of service endpoint with gLite 3.2 available on site.<br />
|-<br />
| align="center" | eu.egi.sec.WMS-gLite-31<br />
| Test queries site BDII for the following pattern "(&(GlueServiceType=org.glite.wms.WMProxy)(GlueServiceVersion=3.2*)(GlueServiceEndpoint=*$HOSTNAME$*))". Returns CRITICAL if query returns any results.<br />
|}<br />
<br />
'''Table below defines mappings between MW tests and service types.'''<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" align="left"<br />
|-<br />
! Service type<br />
! Nagios test <br />
! Comment<br />
|-<br />
| align="center" | CE<br />
| eu.egi.sec.LCG-CE <br />
| <br />
|-<br />
| align="center" rowspan="2" | Central-LFC<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.gLite-32-sup<br />
| <br />
|-<br />
| align="center" | Classic-SE<br />
| eu.egi.sec.Classic-SE <br />
| <br />
|-<br />
| align="center" rowspan="2" | FTS<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.gLite-32-sup<br />
| <br />
|-<br />
| align="center" | gLite-CE<br />
| eu.egi.sec.gLite-CE <br />
| <br />
|-<br />
| align="center" rowspan="2" | Local-LFC<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.gLite-32-sup<br />
| <br />
|-<br />
| align="center" | MON<br />
| eu.egi.sec.MON<br />
| <br />
|-<br />
| align="center" rowspan="2" | MyProxy<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.gLite-32<br />
| <br />
|-<br />
| align="center" | RB<br />
| eu.egi.sec.RB<br />
| <br />
|-<br />
| align="center" rowspan="4" | Site-BDII<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.gLite-32<br />
| <br />
|-<br />
| eu.egi.sec.Total-gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.Total-gLite-32<br />
| <br />
|-<br />
| align="center" rowspan="2" | SRM<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.gLite-32-sup<br />
| <br />
|-<br />
| align="center" rowspan="2" | Top-BDII<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.gLite-32<br />
| <br />
|-<br />
| align="center"| VO-box<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| align="center" rowspan="2" | VOMS<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.gLite-32<br />
| <br />
|-<br />
| align="center"| WMS<br />
| eu.egi.sec.WMS-gLite-31<br />
| <br />
|}</div>Kourilhttps://wiki.egi.eu/w/index.php?title=MW_SAM_tests&diff=41398MW SAM tests2012-10-10T10:32:42Z<p>Kouril: </p>
<hr />
<div>'''Table describes list of tests used for tracking installed MW versions on EGI sites. All tests are executed every 24h.'''<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" align="left"<br />
|-<br />
! Nagios test <br />
! Description<br />
|-<br />
| align="center" | eu.egi.sec.Classic-SE<br />
| Test is associated to Classic-CE service endpoints and it always returns CRITICAL. This service type [[GOCDB/Input_System_User_Documentation#Service_types|has been obsoleted]] for a while and it should be removed from all sites.<br />
|-<br />
| align="center" | eu.egi.sec.CREAMCE-gLite-32<br />
| Test queries site BDII for the following pattern "(&(GlueServiceType=org.glite.ce.CREAM)(GlueServiceVersion=1.12.*)(GlueServiceEndpoint=*$HOSTNAME$*))". Returns CRITICAL if query returns any results.<br />
|-<br />
| align="center" | eu.egi.sec.gLite-CE<br />
| Test is associated to gLite-CE service endpoints and it always returns CRITICAL. This service type [[GOCDB/Input_System_User_Documentation#Service_types|has been obsoleted]] for a while and it should be removed from all sites.<br />
|-<br />
| align="center" | eu.egi.sec.gLite-31<br />
| Test queries site BDII for the following pattern "(&(GlueServiceDataValue=3.1.0)(GlueChunkKey=*$HOSTNAME$*))". Returns CRITICAL if query returns any results.<br />
|-<br />
| align="center" | eu.egi.sec.gLite-32<br />
| Test queries site BDII for the following pattern "(&(GlueServiceDataValue=3.2.0)(GlueChunkKey=*$HOSTNAME$*))". Returns CRITICAL if query returns any results.<br />
|-<br />
| align="center" | eu.egi.sec.gLite-32-sup<br />
| Test queries site BDII for the following pattern "(&(GlueServiceDataValue=3.2.0)(GlueChunkKey=*$HOSTNAME$*))". Returns WARNING if query returns any results. This query is used for gLite 3.2 service types which are supported til the end of November 2012 (see the [http://glite.cern.ch/support_calendar/ gLite 3.2 support calendar]).<br />
|-<br />
| align="center" | eu.egi.sec.LCG-CE<br />
| Test is associated to CE service endpoints and it always returns CRITICAL. LCG-CE is unsupported (see the [http://glite.cern.ch/support_calendar/ gLite 3.2 support calendar]).<br />
|-<br />
| align="center" | eu.egi.sec.MON<br />
| Test is associated to MON service endpoints and it always returns CRITICAL. This service type [[GOCDB/Input_System_User_Documentation#Service_types|has been obsoleted]] for a while and it should be removed from all sites.<br />
|-<br />
| align="center" | eu.egi.sec.RB<br />
| Test is associated to RB service endpoints and it always returns CRITICAL. This service type [[GOCDB/Input_System_User_Documentation#Service_types|has been obsoleted]] for a while and it should be removed from all sites.<br />
|-<br />
| align="center" | eu.egi.sec.Total-gLite-31<br />
| Test queries site BDII for the following pattern "(GlueServiceDataValue=3.1.0)". Returns CRITICAL if query returns any results. At this point query does not create alarm in Dashboard and it is used only as a counter of service endpoint with gLite 3.1 available on site.<br />
|-<br />
| align="center" | eu.egi.sec.Total-gLite-32<br />
| Test queries site BDII for the following pattern "(GlueServiceDataValue=3.2.0)". Returns WARNING if query returns any results. At this point query does not create alarm in Dashboard and it is used only as a counter of service endpoint with gLite 3.2 available on site.<br />
|-<br />
| align="center" | eu.egi.sec.WMS-gLite-31<br />
| Test queries site BDII for the following pattern "(&(GlueServiceType=org.glite.wms.WMProxy)(GlueServiceVersion=3.2*)(GlueServiceEndpoint=*$HOSTNAME$*))". Returns CRITICAL if query returns any results.<br />
|}<br />
<br />
'''Table below defines mappings between MW tests and service types.'''<br />
<br />
{| cellspacing="0" cellpadding="5" border="1" align="left"<br />
|-<br />
! Service type<br />
! Nagios test <br />
! Comment<br />
|-<br />
| align="center" | CE<br />
| eu.egi.sec.LCG-CE <br />
| <br />
|-<br />
| align="center" rowspan="2" | Central-LFC<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.gLite-32-sup<br />
| <br />
|-<br />
| align="center" | Classic-SE<br />
| eu.egi.sec.Classic-SE <br />
| <br />
|-<br />
| align="center" rowspan="2" | FTS<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.gLite-32-sup<br />
| <br />
|-<br />
| align="center" | gLite-CE<br />
| eu.egi.sec.gLite-CE <br />
| <br />
|-<br />
| align="center" rowspan="2" | Local-LFC<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.gLite-32-sup<br />
| <br />
|-<br />
| align="center" | MON<br />
| eu.egi.sec.MON<br />
| <br />
|-<br />
| align="center" rowspan="2" | MyProxy<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.gLite-32<br />
| <br />
|-<br />
| align="center" | RB<br />
| eu.egi.sec.RB<br />
| <br />
|-<br />
| align="center" rowspan="4" | Site-BDII<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.gLite-32<br />
| <br />
|-<br />
| eu.egi.sec.Total-gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.Total-gLite-32<br />
| <br />
|-<br />
| align="center" rowspan="2" | SRM<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.gLite-32-sup<br />
| <br />
|-<br />
| align="center" rowspan="2" | Top-BDII<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.gLite-32<br />
| <br />
|-<br />
| align="center"| VO-box<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| align="center" rowspan="2" | VOMS<br />
| eu.egi.sec.gLite-31<br />
| <br />
|-<br />
| eu.egi.sec.gLite-32<br />
| <br />
|-<br />
| align="center"| WMS<br />
| eu.egi.sec.WMS-gLite-31<br />
| <br />
|}</div>Kourilhttps://wiki.egi.eu/w/index.php?title=VT_Federated_Identity_Providers_Assessment_Task_1:Ireland&diff=31739VT Federated Identity Providers Assessment Task 1:Ireland2012-02-01T13:34:59Z<p>Kouril: </p>
<hr />
<div>* ''Are personal e-Science certificates available through the Terena Certificate Service in your country?''<br />
** ''If yes, contact the NREN/institute/company that provides TCS in your country and check that the information about the available certificate types is up to date on the on the [http://www.terena.org/activities/tcs/participants.html Terena webpage]. If the information is in the list is incorrect, what needs to be fixed?''<br />
** ''If no, are there any plans to introduce the service (including timelines, obstacles identified, etc.)?''<br />
<br />
No. Other TCS services are available<br />
<br />
The Terena webpage says "Personal: No" but https://certificates.heanet.ie/ claims "limited personal certificates" are supported via TCD.<br />
<br />
* ''In order to obtain a personal e-Science certificate from TCS, a user has to be affiliated with an institute that is part of the national identity federation and that has established an appropriate Subscriber Agreement. Please collect information about the institutes from which your NGI expects users (e.g. universities, research institutes) and indicate whether:''<br />
** ''are those institutes members of your country's identity federation,''<br />
<br />
Yes<br />
<br />
** ''have those institutions signed the Subscriber Agreement with the NREN, i.e. whether they allow to issue TCS personal e-Science certificates to their members.''<br />
<br />
No<br />
<br />
* ''What is the process to get a personal e-Science certificate from TCS in your country?''<br />
<br />
Not supported in Ireland.<br />
<br />
* ''What are the rules for an institution in your country to join the identity federation and TCS?''<br />
** ''Is there any special fee that an institution pays for joining TCS and/or the identity federation?''<br />
<br />
Join the federation: http://www.edugate.ie/membership<br />
Apply for TCS access: https://certificates.heanet.ie/node/4<br />
<br />
* ''Does your NGI or NREN provide any service similar to the TCS? Please choose zero or more from the following and provide a brief description:''<br />
<br />
National grid CA is exploring possibility of using federated identity to populate user certificate request web form to classic CA.<br />
<br />
* ''Any comments you have to TCS utilization in your NGI''<br />
<br />
Many Irish IdPs cannot confirm "face-to-face" identity checking of entries in their identity db.<br />
This makes these IdPs ineligible for TCS.</div>Kourilhttps://wiki.egi.eu/w/index.php?title=VT_Federated_Identity_Providers_Assessment_Task_1:Ireland&diff=31738VT Federated Identity Providers Assessment Task 1:Ireland2012-02-01T13:34:25Z<p>Kouril: </p>
<hr />
<div>* ''Are personal e-Science certificates available through the Terena Certificate Service in your country?''<br />
** ''If yes, contact the NREN/institute/company that provides TCS in your country and check that the information about the available certificate types is up to date on the on the [http://www.terena.org/activities/tcs/participants.html Terena webpage]. If the information is in the list is incorrect, what needs to be fixed?''<br />
** ''If no, are there any plans to introduce the service (including timelines, obstacles identified, etc.)?''<br />
<br />
No. Other TCS services are available<br />
<br />
The Terena webpage says "Personal: No" but https://certificates.heanet.ie/ claims "limited personal certificates" are supported via TCD.<br />
<br />
* ''In order to obtain a personal e-Science certificate from TCS, a user has to be affiliated with an institute that is part of the national identity federation and that has established an appropriate Subscriber Agreement. Please collect information about the institutes from which your NGI expects users (e.g. universities, research institutes) and indicate whether:''<br />
** ''are those institutes members of your country's identity federation,''<br />
<br />
Yes<br />
<br />
** ''have those institutions signed the Subscriber Agreement with the NREN, i.e. whether they allow to issue TCS personal e-Science certificates to their members.''<br />
<br />
No<br />
<br />
* ''What is the process to get a personal e-Science certificate from TCS in your country?''<br />
<br />
Not supported in Ireland.<br />
<br />
* ''What are the rules for an institution in your country to join the identity federation and TCS?''<br />
** ''Is there any special fee that an institution pays for joining TCS and/or the identity federation?''<br />
<br />
Join the federation: http://www.edugate.ie/membership<br />
Apply for TCS access: https://certificates.heanet.ie/node/4<br />
<br />
* ''Does your NGI or NREN provide any service similar to the TCS? Please choose zero or more from the following and provide a brief description:''<br />
<br />
National grid CA is exploring possibility of using federated identity to populate user certificate request web form to classic CA.<br />
<br />
<br />
* ''Any comments you have to TCS utilization in your NGI''<br />
<br />
Many Irish IdPs cannot confirm "face-to-face" identity checking of entries in their identity db.<br />
This makes these IdPs ineligible for TCS.</div>Kourilhttps://wiki.egi.eu/w/index.php?title=VT_Federated_Identity_Providers_Assessment_Task_1:Czech_Republic&diff=31737VT Federated Identity Providers Assessment Task 1:Czech Republic2012-02-01T13:33:07Z<p>Kouril: </p>
<hr />
<div>* ''Are personal e-Science certificates available through the Terena Certificate Service in your country?''<br />
** ''If yes, contact the NREN/institute/company that provides TCS in your country and check that the information about the available certificate types is up to date on the on the [http://www.terena.org/activities/tcs/participants.html Terena webpage]. If the information is in the list is incorrect, what needs to be fixed?''<br />
** ''If no, are there any plans to introduce the service (including timelines, obstacles identified, etc.)?''<br />
<br />
Yes, TCS is provided via the NREN operator (CESNET)<br />
The information on the Terena webpages is up to date. The only inaccuracy is the "Czech Republic (CESNET)" link pointing to the manual for TCS server certificates, instead of a general TCS service at CESNET.<br />
<br />
* ''In order to obtain a personal e-Science certificate from TCS, a user has to be affiliated with an institute that is part of the national identity federation and that has established an appropriate Subscriber Agreement. Please collect information about the institutes from which your NGI expects users (e.g. universities, research institutes) and indicate whether:''<br />
** ''are those institutes members of your country's identity federation,''<br />
** ''have those institutions signed the Subscriber Agreement with the NREN, i.e. whether they allow to issue TCS personal e-Science certificates to their members.''<br />
<br />
The majority of Czech universities participate in the SAML nation-wide identity federation. A lot of grid users come from the Academy of Sciences of the Czech Republic, which hasn't joined the federation yet. Some piloting in this regard has been started but no particular deadlines are known at the moment.<br />
<br />
The Academy of sciences has signed Subscriber Agreement.<br />
<br />
* ''What is the process to get a personal e-Science certificate from TCS in your country?''<br />
The process is mediated via a web portal, which is provided by CESNET and which is connected to the TCS. Users authenticate in the usual way, i.e. they select their home organization from a list of institutes that joined TCS. After authentication with their home institute, the users select the type of the certificate to request (ordinary or e-science) and they're navigated through the whole process. The key pair is generated in the browser or users can choose to generate it by other means. The portal requires users to re-authenticate before the certificate is actually issued. The resulting certificate is automatically stored in the browser and bound with the private key.<br />
<br />
* ''What are the rules for an institution in your country to join the identity federation and TCS?''<br />
** ''Is there any special fee that an institution pays for joining TCS and/or the identity federation?''<br />
<br />
The eduid.cz federation is open to any research institution, which has access to the Czech NREN. In order to join the TCS service the organization must fill in a set of forms (essentialy the TCS Subscriber Agreement) and make sure they comply with the requirements of the CPS (esp. they cover sufficiently the user's life cycle, etc.). After the forms are processed CESNET enables the access for the institution.<br />
<br />
There is no fee for joining eduID.cz nor for TCS.<br />
<br />
The documentations and procedures are in Czech only.<br />
<br />
* ''Does your NGI or NREN provide any service similar to the TCS? Please choose zero or more from the following and provide a brief description:''<br />
<br />
There is no such a service.<br />
<br />
* ''Any comments you have to TCS utilization in your NGI''<br />
<br />
The TCS is not well advertised in our country. TCS solves just a part of the credentials management problems since people are still required to handle the files with keys/certificates, which cause problems.</div>Kourilhttps://wiki.egi.eu/w/index.php?title=VT_Federated_Identity_Providers_Assessment_Task_1:Ireland&diff=31735VT Federated Identity Providers Assessment Task 1:Ireland2012-02-01T13:25:57Z<p>Kouril: Blanked the page</p>
<hr />
<div></div>Kourilhttps://wiki.egi.eu/w/index.php?title=VT_Federated_Identity_Providers_Assessment_Task_1:template&diff=31734VT Federated Identity Providers Assessment Task 1:template2012-02-01T13:25:45Z<p>Kouril: Created page with '* ''Are personal e-Science certificates available through the Terena Certificate Service in your country?'' ** ''If yes, contact the NREN/institute/company that provides TCS in y…'</p>
<hr />
<div>* ''Are personal e-Science certificates available through the Terena Certificate Service in your country?''<br />
** ''If yes, contact the NREN/institute/company that provides TCS in your country and check that the information about the available certificate types is up to date on the on the [http://www.terena.org/activities/tcs/participants.html Terena webpage]. If the information is in the list is incorrect, what needs to be fixed?''<br />
** ''If no, are there any plans to introduce the service (including timelines, obstacles identified, etc.)?''<br />
<br />
* ''In order to obtain a personal e-Science certificate from TCS, a user has to be affiliated with an institute that is part of the national identity federation and that has established an appropriate Subscriber Agreement. Please collect information about the institutes from which your NGI expects users (e.g. universities, research institutes) and indicate whether:''<br />
** ''are those institutes members of your country's identity federation,''<br />
** ''have those institutions signed the Subscriber Agreement with the NREN, i.e. whether they allow to issue TCS personal e-Science certificates to their members.''<br />
<br />
* ''What is the process to get a personal e-Science certificate from TCS in your country?''<br />
<br />
* ''What are the rules for an institution in your country to join the identity federation and TCS?''<br />
** ''Is there any special fee that an institution pays for joining TCS and/or the identity federation?''<br />
<br />
* ''Does your NGI or NREN provide any service similar to the TCS? Please choose zero or more from the following and provide a brief description:''<br />
<br />
* ''Any comments you have to TCS utilization in your NGI''</div>Kourilhttps://wiki.egi.eu/w/index.php?title=VT_Federated_Identity_Providers_Assessment_Task_1:Czech_Republic&diff=31733VT Federated Identity Providers Assessment Task 1:Czech Republic2012-02-01T13:18:58Z<p>Kouril: Created page with '* ''Are personal e-Science certificates available through the Terena Certificate Service in your country?'' ** ''If yes, contact the NREN/institute/company that provides TCS in y…'</p>
<hr />
<div>* ''Are personal e-Science certificates available through the Terena Certificate Service in your country?''<br />
** ''If yes, contact the NREN/institute/company that provides TCS in your country and check that the information about the available certificate types is up to date on the on the [http://www.terena.org/activities/tcs/participants.html Terena webpage]. If the information is in the list is incorrect, what needs to be fixed?''<br />
** ''If no, are there any plans to introduce the service (including timelines, obstacles identified, etc.)?''<br />
<br />
Yes, TCS is provided via the NREN operator (CESNET)<br />
The information on the Terena webpages is up to date. The only inaccuracy is the "Czech Republic (CESNET)" link pointing to the manual for TCS server certificates, instead of a general TCS service at CESNET.<br />
<br />
* ''In order to obtain a personal e-Science certificate from TCS, a user has to be affiliated with an institute that is part of the national identity federation and that has established an appropriate Subscriber Agreement. Please collect information about the institutes from which your NGI expects users (e.g. universities, research institutes) and indicate whether:''<br />
** ''are those institutes members of your country's identity federation,''<br />
** ''have those institutions signed the Subscriber Agreement with the NREN, i.e. whether they allow to issue TCS personal e-Science certificates to their members.''<br />
<br />
The majority of Czech universities participate in the SAML nation-wide identity federation. A lot of grid users come from the Academy of Sciences of the Czech Republic, which hasn't joined the federation yet. Some piloting in this regard has been started but no particular deadlines are known at the moment.<br />
<br />
The Academy of sciences has signed Subscriber Agreement.<br />
<br />
* ''What is the process to get a personal e-Science certificate from TCS in your country?''<br />
The process is mediated via a web portal, which is provided by CESNET and which is connected to the TCS. Users authenticate in the usual way, i.e. they select their home organization from a list of institutes that joined TCS. After authentication with their home institute, the users select the type of the certificate to request (ordinary or e-science) and they're navigated through the whole process. The key pair is generated in the browser or users can choose to generate it by other means. The portal requires users to re-authenticate before the certificate is actually issued. The resulting certificate is automatically stored in the browser and bound with the private key.<br />
<br />
* ''What are the rules for an institution in your country to join the identity federation and TCS?''<br />
** ''Is there any special fee that an institution pays for joining TCS and/or the identity federation?''<br />
<br />
The eduid.cz federation is open to any research institution, which has access to the Czech NREN. In order to join the TCS service the organization must fill in a set of forms (essentialy the TCS Subscriber Agreement) and make sure they comply with the requirements of the CPS (esp. they cover sufficiently the user's life cycle, etc.). After the forms are processed CESNET enables the access for the institution.<br />
<br />
There is no fee for joining eduID.cz nor for TCS.<br />
<br />
* ''Does your NGI or NREN provide any service similar to the TCS? Please choose zero or more from the following and provide a brief description:''<br />
<br />
There is no such a service.<br />
<br />
* ''Any comments you have to TCS utilization in your NGI''<br />
<br />
The TCS is not well advertised in our country. TCS solves just a part of the credentials management problems since people are still required to handle the files with keys/certificates, which cause problems.</div>Kourilhttps://wiki.egi.eu/w/index.php?title=VT_Federated_Identity_Providers_Assessment&diff=31732VT Federated Identity Providers Assessment2012-02-01T13:18:25Z<p>Kouril: </p>
<hr />
<div>{{VirtualTeamProject | <br />
VTP_Leader = Daniel Kouril (CESNET) |<br />
VTP_ML = vt-egi-federated-identity@mailman.egi.eu |<br />
VTP_Status = Active |<br />
VTP_StartDate = 10/Nov/2011 |<br />
VTP_EndDate = When its goal is achiveved, but not later than 30/Apr/2012 | <br />
VTP_Motivation = <br />
Federated identity services could significantly simplify access to the infrastructure. Introducing federated identity mechanisms in EGI is a requirement from many communities. <br />
This VT project would take a step towards this direction, by assessing the readiness of the NGIs in adopting some type of federated identity provision mechanism for accessing services (e.g. Terena Certificate Services). Several NGIs have done developments towards this direction. <br />
|<br />
VTP_Meetings = <br />
[[12/12/2011 - Kick-off meeting]] <br />
|<br />
VTP_Output = <br />
The expected output of this project '''is a report''' on the current coverage of NGIs with federated identity provision services and recommendation on mechanisms to increase the federated identity providers coverage within EGI. The report can be used by both NGIs and EGI.eu outside of this VT to increase the coverage or to initiate other types of related actions. <br />
| <br />
VTP_Tasks = <br />
=== Task 1: Assess the coverage of Terena Certificate Providers in NGIs === <br />
* Check whether the key institutes form the NGIs are connected to the TCS<br />
* Check whether the NGIs have process to add institutes to TCS and what the process look like<br />
* Collect info about other types of services similar to TCS that NGIs already use<br />
<br />
==== Actions ====<br />
* Fill in the [[Task 1: Questionnaire about TCS|questionnaire]] (all participating NGIs)<br />
* Completed questionnaires:<br />
** [[Task 1:Ireland|Ireland]], [[Task 1:Czech Republic|Czech Republic]], ''[[Task 1:template|template]]''<br />
|<br />
VTP_Team =<br />
* NGIs: <br />
** Czech Republic: Daniel Kouril (Leader), Michal Prochazka<br />
** France: Genevieve Romier <br />
** Greece: Kostas Koumantaros, Christos Kanelopoulos<br />
** Ireland: David O'Callaghan<br />
** Italy: Marco Bencivenni, Enrico Fattibene, Daniele Cesini, Roberto Barbera, Marco Fargetta<br />
** Germany: Torsten Antoni<br />
** Switzerland: Simon Leinen<br />
* EGI.eu: <br />
** Gergely Sipos<br />
|<br />
VTP_Resources = <br />
* List of TERENA certificate providers: http://www.terena.org/activities/tcs/participants.html<br />
* Federated web services: http://atlases.muni.cz<br />
* Mechanism to release a x509 certificate in a user-transparent way from an online CA: http://wiki.italiangrid.it/twiki/pub/UserSupport/NGIITGeneralPurposePortal/Whitepaper-portal-CAonline-interaction.pdf <br />
* Edugate: Federation of Irish Higher Education Institutions and Research Organisations: http://www.edugate.ie/<br />
* EduGAIN: "Federation of the federations": http://www.geant.net/service/edugain/pages/home.aspx<br />
* Moonshot: Passing identity federations into the non-web world: http://www.project-moonshot.org/<br />
}}</div>Kourilhttps://wiki.egi.eu/w/index.php?title=VT_Federated_Identity_Providers_Assessment_Task_1:Ireland&diff=31731VT Federated Identity Providers Assessment Task 1:Ireland2012-02-01T13:17:05Z<p>Kouril: Created page with '* ''Are personal e-Science certificates available through the Terena Certificate Service in your country?'' ** ''If yes, contact the NREN/institute/company that provides TCS in y…'</p>
<hr />
<div>* ''Are personal e-Science certificates available through the Terena Certificate Service in your country?''<br />
** ''If yes, contact the NREN/institute/company that provides TCS in your country and check that the information about the available certificate types is up to date on the on the [http://www.terena.org/activities/tcs/participants.html Terena webpage]. If the information is in the list is incorrect, what needs to be fixed?''<br />
** ''If no, are there any plans to introduce the service (including timelines, obstacles identified, etc.)?''<br />
<br />
Yes, TCS is provided via the NREN operator (CESNET)<br />
The information on the Terena webpages is up to date. The only inaccuracy is the "Czech Republic (CESNET)" link pointing to the manual for TCS server certificates, instead of a general TCS service at CESNET.<br />
<br />
* ''In order to obtain a personal e-Science certificate from TCS, a user has to be affiliated with an institute that is part of the national identity federation and that has established an appropriate Subscriber Agreement. Please collect information about the institutes from which your NGI expects users (e.g. universities, research institutes) and indicate whether:''<br />
** ''are those institutes members of your country's identity federation,''<br />
** ''have those institutions signed the Subscriber Agreement with the NREN, i.e. whether they allow to issue TCS personal e-Science certificates to their members.''<br />
<br />
The majority of Czech universities participate in the SAML nation-wide identity federation. A lot of grid users come from the Academy of Sciences of the Czech Republic, which hasn't joined the federation yet. Some piloting in this regard has been started but no particular deadlines are known at the moment.<br />
<br />
The Academy of sciences has signed Subscriber Agreement.<br />
<br />
* ''What is the process to get a personal e-Science certificate from TCS in your country?''<br />
The process is mediated via a web portal, which is provided by CESNET and which is connected to the TCS. Users authenticate in the usual way, i.e. they select their home organization from a list of institutes that joined TCS. After authentication with their home institute, the users select the type of the certificate to request (ordinary or e-science) and they're navigated through the whole process. The key pair is generated in the browser or users can choose to generate it by other means. The portal requires users to re-authenticate before the certificate is actually issued. The resulting certificate is automatically stored in the browser and bound with the private key.<br />
<br />
* ''What are the rules for an institution in your country to join the identity federation and TCS?''<br />
** ''Is there any special fee that an institution pays for joining TCS and/or the identity federation?''<br />
<br />
The eduid.cz federation is open to any research institution, which has access to the Czech NREN. In order to join the TCS service the organization must fill in a set of forms (essentialy the TCS Subscriber Agreement) and make sure they comply with the requirements of the CPS (esp. they cover sufficiently the user's life cycle, etc.). After the forms are processed CESNET enables the access for the institution.<br />
<br />
There is no fee for joining eduID.cz nor for TCS.<br />
<br />
* ''Does your NGI or NREN provide any service similar to the TCS? Please choose zero or more from the following and provide a brief description:''<br />
<br />
There is no such a service.<br />
<br />
* ''Any comments you have to TCS utilization in your NGI''<br />
<br />
The TCS is not well advertised in our country. TCS solves just a part of the credentials management problems since people are still required to handle the files with keys/certificates, which cause problems.</div>Kourilhttps://wiki.egi.eu/w/index.php?title=VT_Federated_Identity_Providers_Assessment&diff=31726VT Federated Identity Providers Assessment2012-02-01T12:28:10Z<p>Kouril: </p>
<hr />
<div>{{VirtualTeamProject | <br />
VTP_Leader = Daniel Kouril (CESNET) |<br />
VTP_ML = vt-egi-federated-identity@mailman.egi.eu |<br />
VTP_Status = Active |<br />
VTP_StartDate = 10/Nov/2011 |<br />
VTP_EndDate = When its goal is achiveved, but not later than 30/Apr/2012 | <br />
VTP_Motivation = <br />
Federated identity services could significantly simplify access to the infrastructure. Introducing federated identity mechanisms in EGI is a requirement from many communities. <br />
This VT project would take a step towards this direction, by assessing the readiness of the NGIs in adopting some type of federated identity provision mechanism for accessing services (e.g. Terena Certificate Services). Several NGIs have done developments towards this direction. <br />
|<br />
VTP_Meetings = <br />
[[12/12/2011 - Kick-off meeting]] <br />
|<br />
VTP_Output = <br />
The expected output of this project '''is a report''' on the current coverage of NGIs with federated identity provision services and recommendation on mechanisms to increase the federated identity providers coverage within EGI. The report can be used by both NGIs and EGI.eu outside of this VT to increase the coverage or to initiate other types of related actions. <br />
| <br />
VTP_Tasks = <br />
=== Task 1: Assess the coverage of Terena Certificate Providers in NGIs === <br />
* Check whether the key institutes form the NGIs are connected to the TCS<br />
* Check whether the NGIs have process to add institutes to TCS and what the process look like<br />
* Collect info about other types of services similar to TCS that NGIs already use<br />
<br />
==== Actions ====<br />
* Fill in the [[Task 1: Questionnaire about TCS|questionnaire]] (all participating NGIs)<br />
* Completed questionnaires:<br />
** [[Task 1:Ireland|Ireland]], [[Task 1:Czech Republic|Czech Republic]]<br />
|<br />
VTP_Team =<br />
* NGIs: <br />
** Czech Republic: Daniel Kouril (Leader), Michal Prochazka<br />
** France: Genevieve Romier <br />
** Greece: Kostas Koumantaros, Christos Kanelopoulos<br />
** Ireland: David O'Callaghan<br />
** Italy: Marco Bencivenni, Enrico Fattibene, Daniele Cesini, Roberto Barbera, Marco Fargetta<br />
** Germany: Torsten Antoni<br />
** Switzerland: Simon Leinen<br />
* EGI.eu: <br />
** Gergely Sipos<br />
|<br />
VTP_Resources = <br />
* List of TERENA certificate providers: http://www.terena.org/activities/tcs/participants.html<br />
* Federated web services: http://atlases.muni.cz<br />
* Mechanism to release a x509 certificate in a user-transparent way from an online CA: http://wiki.italiangrid.it/twiki/pub/UserSupport/NGIITGeneralPurposePortal/Whitepaper-portal-CAonline-interaction.pdf <br />
* Edugate: Federation of Irish Higher Education Institutions and Research Organisations: http://www.edugate.ie/<br />
* EduGAIN: "Federation of the federations": http://www.geant.net/service/edugain/pages/home.aspx<br />
* Moonshot: Passing identity federations into the non-web world: http://www.project-moonshot.org/<br />
}}</div>Kourilhttps://wiki.egi.eu/w/index.php?title=VT_Federated_Identity_Providers_Assessment_Task_1:_Questionnaire_about_TCS&diff=31285VT Federated Identity Providers Assessment Task 1: Questionnaire about TCS2012-01-24T13:18:11Z<p>Kouril: </p>
<hr />
<div>==== Assessing the TCS coverage of your country ====<br />
This questionnaire is part of an assessment of the readiness of the NGIs in<br />
adopting some type of federated identity provision mechanism for accessing<br />
services, such as the Terena Certificate Services (TCS). In order to prepare your<br />
response, please consult the [http://www.terena.org/activities/tcs/participants.html Terena Certificate Services participants list.<br />
<br />
# Are personal e-Science certificates available through the Terena Certificate Service in your country?<br />
#* If yes, contact the NREN/institute/company that provides TCS in your country and check that the information about the available certificate types is up to date on the on the [http://www.terena.org/activities/tcs/participants.html Terena webpage]. If the information is in the list is incorrect, what needs to be fixed?<br />
#* If no, are there any plans to introduce the service (including timelines, obstacles identified, etc.)?<br />
# In order to obtain a personal e-Science certificate from TCS, a user has to be affiliated with an institute that is part of the national identity federation and that has established an appropriate Subscriber Agreement. Please collect information about the institutes from which your NGI expects users (e.g. universities, research institutes) and indicate whether:<br />
#* are those institutes members of your country's identity federation,<br />
#* have those institutions signed the Subscriber Agreement with the NREN, i.e. whether they allow to issue TCS personal e-Science certificates to their members.<br />
# What is the process to get a personal e-Science certificate from TCS in your country?<br />
# What are the rules for an institution in your country to join the identity federation and TCS?<br />
#* Is there any special fee that an institution pays for joining TCS and/or the identity federation?<br />
# Does your NGI or NREN provide any service similar to the TCS? Please choose zero or more from the following and provide a brief description:<br />
#* IGTF accredited MICS CA using federated identity<br />
#* IGTF accredited Classic CA using federated identity<br />
#* IGTF accredited Classic CA using federated identity<br />
#* Non-accredited local/national MICS CA using federated identity<br />
#* Non-accredited local/national SLCS CA using federated identity<br />
#* Federated identity grid access via web portal<br />
#* Other (give details)<br />
# Any comments you have to TCS utilization in your NGI<br />
#* Users' experience with obtaining TCS certificates, complexity of introduction of the TCS, any experience with the process of joining of institution in you country, only limited TCS service (i.e. support for only some TCS CAs, explain why), etc.</div>Kourilhttps://wiki.egi.eu/w/index.php?title=VT_Federated_Identity_Providers_Assessment&diff=31284VT Federated Identity Providers Assessment2012-01-24T13:09:20Z<p>Kouril: </p>
<hr />
<div>{{VirtualTeamProject | <br />
VTP_Leader = Daniel Kouril (CESNET) |<br />
VTP_ML = vt-egi-federated-identity@mailman.egi.eu |<br />
VTP_Status = Active |<br />
VTP_StartDate = 10/Nov/2011 |<br />
VTP_EndDate = When its goal is achiveved, but not later than 30/Apr/2012 | <br />
VTP_Motivation = <br />
Federated identity services could significantly simplify access to the infrastructure. Introducing federated identity mechanisms in EGI is a requirement from many communities. <br />
This VT project would take a step towards this direction, by assessing the readiness of the NGIs in adopting some type of federated identity provision mechanism for accessing services (e.g. Terena Certificate Services). Several NGIs have done developments towards this direction. <br />
|<br />
VTP_Meetings = <br />
[[12/12/2011 - Kick-off meeting]] <br />
|<br />
VTP_Output = <br />
The expected output of this project '''is a report''' on the current coverage of NGIs with federated identity provision services and recommendation on mechanisms to increase the federated identity providers coverage within EGI. The report can be used by both NGIs and EGI.eu outside of this VT to increase the coverage or to initiate other types of related actions. <br />
| <br />
VTP_Tasks = <br />
=== Task 1: Assess the coverage of Terena Certificate Providers in NGIs === <br />
* Check whether the key institutes form the NGIs are connected to the TCS<br />
* Check whether the NGIs have process to add institutes to TCS and what the process look like<br />
* Collect info about other types of services similar to TCS that NGIs already use<br />
<br />
==== Actions ====<br />
* Fill in the [[Task 1: Questionnaire about TCS|questionnaire]] (all participating NGIs)<br />
|<br />
VTP_Team =<br />
* NGIs - confirmed: <br />
** Czech Republic: Daniel Kouril (Leader), Michal Prochazka<br />
** France: Genevieve Romier <br />
** Greece: Kostas Koumantaros, Christos Kanelopoulos<br />
** Ireland: David O'Callaghan<br />
** Italy: Marco Bencivenni, Enrico Fattibene, Daniele Cesini, Roberto Barbera, Marco Fargetta<br />
** Germany: Torsten Antoni<br />
** Switzerland: Simon Leinen<br />
* EGI.eu: <br />
** Gergely Sipos<br />
|<br />
VTP_Resources = <br />
* List of TERENA certificate providers: http://www.terena.org/activities/tcs/participants.html<br />
* Federated web services: http://atlases.muni.cz<br />
* Mechanism to release a x509 certificate in a user-transparent way from an online CA: http://wiki.italiangrid.it/twiki/pub/UserSupport/NGIITGeneralPurposePortal/Whitepaper-portal-CAonline-interaction.pdf <br />
* Edugate: Federation of Irish Higher Education Institutions and Research Organisations: http://www.edugate.ie/<br />
* EduGAIN: "Federation of the federations": http://www.geant.net/service/edugain/pages/home.aspx<br />
* Moonshot: Passing identity federations into the non-web world: http://www.project-moonshot.org/<br />
}}</div>Kourilhttps://wiki.egi.eu/w/index.php?title=VT_Federated_Identity_Providers_Assessment_Task_1:_Questionnaire_about_TCS&diff=31283VT Federated Identity Providers Assessment Task 1: Questionnaire about TCS2012-01-24T12:40:21Z<p>Kouril: /* Assessing the TCS coverage of your country */</p>
<hr />
<div>==== Assessing the TCS coverage of your country ====<br />
This questionnaire is part of an assessment of the readiness of the NGIs in<br />
adopting some type of federated identity provision mechanism for accessing<br />
services, such as the Terena Certificate Services (TCS). In order to prepare your<br />
response, please consult the [http://www.terena.org/activities/tcs/participants.html Terena Certificate Services participants list.<br />
<br />
# Are personal e-Science certificates available through the Terena Certificate Service in your country?<br />
#* If yes, contact the NREN/institute/company that provides TCS in your country and check that the information about the available certificate types is up to date on the on the [http://www.terena.org/activities/tcs/participants.html Terena webpage]. If the information is in the list is incorrect, what needs to be fixed?<br />
#* If no, are there any plans to introduce the service (including timelines, obstacles identified, etc.)?<br />
# In order to obtain a personal e-Science certificate from TCS, a user has to be affiliated with an institute that is part of the national identity federation and that has established an appropriate Subscriber Agreement. Please collect information about the institutes from which your NGI expects users (e.g. universities, research institutes) and indicate whether:<br />
#* are those institutes members of your country's identity federation,<br />
#* have those institutions signed the Subscriber Agreement with the NREN, i.e. whether they allow to issue TCS personal e-Science certificates to their members.<br />
# What is the process to get a personal e-Science certificate from TCS in your country?<br />
# What are the rules for an institution in your country to join the identity federation and TCS?<br />
#* Is there any special fee that an institution pays for joining TCS and/or the identity federation?<br />
# Does your NGI or NREN provide any service similar to the TCS? Please choose zero or more from the following and provide a brief description:<br />
#* IGTF accredited MICS CA using federated identity<br />
#* IGTF accredited Classic CA using federated identity<br />
#* IGTF accredited Classic CA using federated identity<br />
#* Non-accredited local/national MICS CA using federated identity<br />
#* Non-accredited local/national SLCS CA using federated identity<br />
#* Federated identity grid access via web portal<br />
#* Other (give details)<br />
# Any comments you have to TCS utilization in your NGI<br />
#* Users' experience with obtaining TCS certificates, complexity of its introduction, any experience with the process of joining of institution in you country, etc.</div>Kouril