GridPP Technical Meeting - Security training

Friday 23 May 2025, 11:00 → 12:30 Europe/London

Virtual Only

Brij Kishor Jashal (Rutherford appelton laboratory)

Weekly meeting slot for technical topics. We will try and focus on one topic per meeting.  We will announce at the Tuesday Ops meeting if this meeting is going ahead and if so the topic to be discussed.

## GridPP Security Training Tech meeting
Intent for the Day - Run through the topics covered in Security Cern School & then discussion on training topics people think they'll benefit from.

*Slides from school, describing the motivation for the school*

**Appropriate Skills in the Appropriate Places**

Typically 3 types of folks in our environment:  
* Users
* System Managers
* Dedicated Cyber Security Professionals
- Building a community of practice

Note the difference between R&D and Corporate Security
- Focus on understanding risk, as it's a good "shared language"

Approach using NIST Cybersecurity Framework (v2) categories.
- described, a lot in the terms of risk

* Run through of the school's programme (all materials available).
- Sven's risk management encouraged not drilling into technical details too soon
- Moved on to some practical exercises
- Putting it all together
- Incident Response Management
- Forensics
- Using SOCs
- IR exercise

School was extremely successful and well engaged. 

*Opening floor to the zoom room asking which areas for GridPP which we'd benefit for training withing*

* Matt suggests containers as a subject, as now a de facto way of deploying services (Matt went to the first sec school)
* Tom B was at this year's, notes that containers are indeed a topic of interest.
** Security processes and policy discussions were useful for the tier 1 - during review don't always know what best practice, school allowed to "set a bar", give a sense of perspective of where we currently are and where we wish to be.

* DavidC asks if we had one day of in person security training what would you like to cover.
** TomB - what to do in certain situations - what to proceed if what we do, especially in the "heat of the moment"
** Brij - when filling in survey forms for infrastructure security information found usefu, can we establish baselines? DavidC will follow up.
** DavidC - baselines being set for sites is something that has some thought.
** Mitch (chat) - Setting up and opperating of logging and how to effectively monitor those (without having masses of time to assign to do that monitoring)
** Sam (chat) - I think the policy thing is also a "having a flowchart" is also helpful (That is, an "in emergency, follow this chart" thing)
** Benjamin (chat) - I think we need to start with formalised roles and responsibilities - who is responsible for each of the NIST elements.  Then you can determine who needs training on what.  Take incident response; who coordinates?  Who’s responsible for technical analysis?  Might be not point training sites to be ‘crisis managers’ if the responsibility is to collect artefacts etc.
*** DavidC - we will likely need to add in targetted training
** Emanuele - more than incident response ... what about training on how to avoid incidents? :) what common practices and periodic checks we can run at site to identify any potential issue
** DavidC - Work has been made to set up controls, so we should look at what sets are appropriate for us
** Matt - should make sure any in person training benefits from the in person, full of discussion. Recommend "basics", Detection/Protection in the morning, afternoon response.
** Benjamin (in chat): As much as I always default to IR as it’s wonderfully geeky; agreed!  All elements of NIST are important, but who’s responsible for what… ?  And how to do you make it work in our distributed environment. Base security standard if you want to participate in GridPP?  (Informed by risks faced by GridPP?)
** Mitch (chat) - Any additional hardening/security r.e. IPv6?
*** Indeed

David asks if a base security standard would be worry/concern for anyone to implement?

TomB brings up question of scope. Don't want to make it to niche or too broad.  
Sam brings up working with local security, expectations there.
David agrees, and admits to be somewhat deliberately provocative.

Benjamin (chat) - Partly welcome as it would help discussions but in current financial climate, would need to be pragmatic / phased. Or even just a ‘you must have a policy on….’.

Mitch (chat) - Maybe a priority list e.g. Must have - desirable - local policy - if time/effort permits
Matt (chat) - "MUSTS" and "SHOULDS"

David - will pull this from existing materials/work, baring in mind our risk environment.

(tangent) - one of David's goals this year is build paths through the myriad of training materials we have available to us

**Round table**
* Vip - nice to have specific incident response training, also when and where would we do it? Also can we keep documentation brief.
** DC - essentials and "deeper dives"
* Benjamin - IR is fun, but opens up cans of works. Expectation? But might not come out until the training. Looking at NIS and agreeing to who is responsible for what is hard in a federated environment. Notes that responsibilities are fragmented. Requirements, and the need for a baseline.
* Emanuele - practical instructions, checking your site
* Jyothish - how much can be automated? Scripts that can check for common problems.
** Comes into common monitoring.
* Katy - good to have examples to look out for, like unusual behaviour
* Sam - remembers we used to regularly run for common signatures of root kits "back in day", but this fell out. Not sure why. Coming full circle.
** Agreed
* Alex - incident detection, service checking
* Mark - echo Vip and Emanuele, for one man band sites useful to have short, to the point instructions, howtos, requirements to check if following best practice. Needs as much bang for the buck as possible considering effort restrictions.
* Mitch (chat) - I'll have to echo Mark there, being a one man band there's very little time to implement all but the most important of things.
* Vip (chat) - https://gitlab.cern.ch/ComputerSecurity/public/forensics/-/blob/master/documentation/cern-forensics-cheatsheet-1.7.pdf?ref_type=heads 

DaveB, Sam and DavidC started plans at WLCG, will start from the top and drill down. Will in parallel start building training, aiming for a one day training on a date to be decided, and will also work on online training.

Mark - would benefit from a general, dedicate security training and just having materials available.

DavidC - this is going to be a community effort.

Closing thoughts:  
Sam - how concerned are we having considering current geopolitical climate.
Out of scope for this meeting :-)

Matt - useful to set an aspirational time frame for this, something to aim for. Matt suggests O(October).
DavidC - aim for post summer.

Brij suggests Ambleside?  
Holding alongside GridPP at Ambleside might be a push. If carved into two half days might work - will look into this 

Benjamin (chat) - Probably easier to extend Ambleside than set up a new meeting.