Finding Happiness Through Positive Thinking
In this lesson, inspired by Suzanne Dailey, discover the power of optimistic thinking to cultivate happiness in everyday life. Learn to shift from 'What if' to 'Even if' mindset with simple examples and insights from Miss Zeleznik. Embrace the bright side of situations and explore ways to foster a positive outlook regardless of challenges or uncertainties. Join the journey of changing perspectives and finding joy in the simple things.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Software Vulnerabilities - consistency and sharing the load. Linda Cornwall, UKRI/STFC/RAL Iris Collaboration meeting July 2024
Contents Brief description of the EGI Software Vulnerability Group (SVG) Why important? Generalizing what we have learnt to cover other distributed computing infrastructures Ideas on how we can use this experience to work with/for IRIS for everyone s mutual benefit
Purpose of the EGI Software Vulnerability Group (SVG) To minimize the risk of security incidents due to software vulnerabilities.
Very brief History of the EGI SVG Started with a clearly defined procedure around 2006 mainly to handle vulnerabilities in Grid Middleware which were not being handled elsewhere Making sure they are fixed, and updates deployed EGI started in 2010 Evolved gradually to more general Software Vulnerability handling to handle vulnerabilities which affect the EGI infrastructure. Assessing the risk, taking account of the risk due to the way software is used in the Grid infrastructure and in EGI more generally. Continues to evolve needs some changes which are currently under discussion to cope with more diverse/less homogenous infrastructure
Basic Procedure of the EGI SVG Anyone may report an issue - by e-mail to report-vulnerability (at) egi.eu If it has not been announced/software provider not aware of it, SVG contacts the software provider and the software provider investigates (with SVG members, reporter, others, as is relevant.) This is getting rare most vulnerabilities now are publicly announced The relevance and effect in EGI are determined. Risk Assessment is carried out (CRITICAL, HIGH, MODERATE or LOW risk) Note that Risk is related to the EGI shared environment.
Basic SVG procedure contd. If not fixed (mainly for software written by our collaborators - getting rarer), Target Date set Critical - special procedure according to circumstances High - 6 weeks Moderate - 4 months Low - 1 year Advisory sent for all if Critical or High (when fixed or mitigating action recommended) for others only when software written by our collaborators, or other good reason. Sent to site and NGI security contacts lists (Generated from GOCDB) We also sometimes send ALERT , HEADS UP , INFORMATION
SVG and EGI CSIRT The EGI Computer Security Incident Response Team (CSIRT) and SVG work very closely together CSIRT monitors sites for vulnerabilities assessed as Critical by the EGI SVG And may suspend sites exposing vulnerabilities who don t respond to them All those who take an Incident Response Task Force (IRTF) duty are members of SVG Can see the vulnerabilities reported as well as contribute to assessing them And can act in any way they wish, including before SVG has assessed (I don t think this has ever happened)
Who else gets EGI SVG advisories? GridPP sites have been getting them from the start (they are EGI sites as well as part of IRIS) We also send our advisories to OSG security list, who also share their information with us We also send to a person at FermiLab, and a couple of people in EUDAT. We have recently also started sending to IRIS vulnerabilities list
Hopefully we have helped prevent incidents in EGI There is no parallel Universe where this activity didn t take place, to compare to in order to find out how many incidents have been prevented !
Some say we dont need to handle vulnerabilities Why not just trust that Services update, rather like our mobile phones? Much of the software e.g. Linux may automatically update. Why not just assume sites, services and facilities are competent and keep services patched? Sites can easily look at advisories, make judgments for themselves. Sites are responsible for their own security Which IS true
We think SVGs vulnerability handling is important It helps sites and data centres stay secure, especially if there are less experienced staff Helps share the load Sometimes due to the way software is used in a distributed infrastructure a vulnerability may pose a higher risk There may be other action, such as a configuration change which may be appropriate in a distributed environment Some software in use may be non-standard, e.g. written by those with which we collaborate with This is getting less common User communities need to be confident that security is consistent in the distributed infrastructure they use. EGI also monitors sites for critical vulnerabilities, and contacts those exposing any defined as Critical
Other things noted From the GridPP security survey Within GridPP there is a wish to share good practice concerning security Advisories on vulnerabilities appreciated In EGI, getting new people to join SVG is an issue Particularly expertise on distributed services other than Grid Tried to get more people involved, some success, but not enough Scope inevitably depends on participation Depends on experts in software/setups
Generalizing what we have learnt to cover other distributed computing infrastructures The effect of software vulnerabilities varies according to the environment Some (e.g.) Linux vulnerabilities which result in privilege escalation are more serious in a distributed infrastructure 1000s can potentially exploit them Therefore, higher risk Where people manage similar setups at multiple sites sharing information on what to do helps people stay secure If a group of people look out for and assess vulnerabilities it shares the load. Within a distributed infrastructure, good to have consistency concerning vulnerabilities and other security aspects. And there is the software specific to a particular type of infrastructure Vulnerabilities need to be dealt with
And now for IRIS more generally Do we want to setup a new group of people within IRIS to look at and handle Software Vulnerabilities? And exchange information with EGI and others? Beyond what is already being done? Any other ways we want to do some information/workload sharing concerning security? We can discuss here And further in the Security BOF on Wednesday
