1. Proposed mid-term Security Strategies for CERN Prepared by ad-hoc working group members: Lionel Cons, Francois Fluckiger, Denise Heagerty, Jan Iven, Jean-Michel Jouanigot, Alberto Pace

2. Intrusion Trends Break-ins are devious and difficult to detect Determined individuals targeting specific systems Rootkits found on Linux and Windows systems Worms are spreading within seconds Infections during installation sequence (before patches applied) Poorly secured systems are being targeted Weak passwords, unpatched software, insecure configurations Break-ins occur before the fix is out Systems compromised before a patch and/or anti-virus available People are increasingly the weakest link Attackers target users to exploit security holes Infected laptops are physically carried on site Users download malware and open tricked attachments

3. Security Goals Keep the site working effectively and able to assure the organisation's mandate Prevent/Limit the impact of incidents based on their risks. Specifically: Pro-actively alert/protect against common and likely attacks Rapidly isolate systems placing the site at risk For services, ensure that security incidents do not adversely affect the service definition levels (availability, privacy,...) Balance the cost of an incident against the cost of the ability to prevent it Ensure the ability to record, measure and control risks (human, financial, image,...)

4. Summary of Proposals Maximise use of centrally managed services and groups Adapt security levels based on groups of devices or users Provide connectivity management for network devices Reduce the ability for worms to spread inside CERN’s networks Promote the use of “gateways” Protect sensitive equipment and critical services Strengthen authentication and access controls Prevent intruders gaining access to CERN resources Strengthen computing rules Balance academic freedom with its risks and costs Ensure security training and clear responsibilities For each part of a software/product life cycle (specification, design, development, deployment, maintenance, purchase, use, …)

5. Provide Connectivity Management Restrict network access based on connectivity needs: Implement default firewall filtering that protects networked systems from common Internet threats Prevent Internet access for server applications by default with a procedure for handling exceptions Provide coarse-grained network connectivity management for devices reduce the ability for worms and intruders to reach a device permit access to only pre-defined groups e.g. “static devices”, ”DHCP devices”, “off-site” Allow fine grained connectivity management implemented by system specific firewalls

6. Strengthen Authentication Enhance the security of the existing password management process Includes account management and authenticated applications Provide two-factor authentication for users needing additional security Something you have plus something you know, e.g. a One Time Password generator protected by a PIN code Prevent that discovered passwords can be re-used Provide the ability for users and/or service managers to limit the scope for sharing a master credential across services Different services may have different security risks Allow Single Sign On, but with possibility to “opt out” for some services

7. Feedback Your feedback is required and can be sent to Proj-sec@cern.ch A draft document describing Proposed mid-term Security Strategies for CERN is at: http://cern.ch/security/doc

8. Licence Monitoring on Windows and Mac Clients Alan Silverman DTF, 14 th April 2005

9. The Problems 1.Although for some products we have site licensing (e.g. Windows client and Office), for many we need to estimate a usage count (Microsoft Visual Studio, Adobe products, Labview, Exceed, etc). Too low a value could leave us exposed to legal challenges, too high and we would be wasting resources. 2.On the Mac side, the situation is -- except for the OSX bundle and the Microsoft site licence – not transparent. Estimates made until now (for example as presented to the November 2004 DTF) are not thought to be realistic, based largely on feedback to mailed queries.

10. The Solution Licence monitoring obviously exist for both platforms. It would be preferable to use the same tool on both platforms. The Software Licence Office has already a scheme to gather and present usage statistics, the data largely based on the use of FlexLM and similar licensing tools. But the products we want to add mostly use different tools.

11. The Implementation On NICE (SMS already installed), we will collect the usage information on commercial tools which are centrally licensed. Owners of non-NICE Windows PCs wishing to use centrally-licensed software should contact us. On Mac, users wishing access to centrally-licensed software will be requested to install K2 (which will be set to monitor those packages – and only those packages) Users on Windows or Macs who refuse to install SMS or K2 respectively will not be granted access to centrally- licensed software. And FI Purchasing will need special justification to purchase individual licences of such centrally-licensed software for CERN users.