Information Security Management Incidents in Research – Development

The Romanian Review Precision Mechanics, Optics & Mechatronics, 2014, No. 45 137

INFORMATION SECURITY MANAGEMENT INCIDENTS IN RESEARCH – DEVELOPMENT

Carmen Finat,

National Institute of Research and Development in Mechatronics and Measurement Technique, 6-8 Pantelimon Road, 2nd district, Bucharest, Romania

Email: carmen.finat@incdmtm.ro

Abstract Information Security Incident Management aims to provide a quick, efficient and organized response in case of an event and / or security incident. This ensures that, regardless of the circumstances of a security incident, a centralized, uniform process of incident management takes place. This process must provide enough information so that R & D organization can act to ensure that: • If possible, such events and / or incidents will not occur; • There have been restored existing security measures. To understand this process it is necessary to define specific terms and explanation of abbreviations used in the article. Keywords: quality management, security incident, strategy.

1. Introduction Definitions:

Specific terms Quality Management and Information Security are in accordance with international standards EN ISO 9000:2006, ISO / IEC 27001:2006 and ISO / IEC 27002:2008.

Event Security (ES) - an event identified on the state of a system, service or network, signaling a possible breach of information security policy or failure of a security measure or a previously unknown situation, relevant security wise.

Security Incident (IS) - one or more unwanted or unexpected information security events that have a substantial likelihood of compromising the organization's research and development operations and are threatening information security.

Threat: A potential cause of an unwanted incident which may affect a system or a research and development organization.

Vulnerability: one or more sticking points of a resource that can be exploited by a threat, a set of existing conditions that may allow a threat to affect a resource.

2. Abbreviations

RIS: Responsible for Information Security, CRSI

Coordinator. SCP: sole contact person designated by RIS for

taking reports of events and / or security incidents. BEIS Owner.

CRSI: Collective Response to Security Incidents - team in the research and development organization

whose members trust each other, have converging professional skills and will treat information security incidents throughout their life.

FRSI: Form for reporting security incidents. IPM: information processing means. DESI: database events and / or security

incidents, including information about the type, nature of the threat, the financial impact solution addressed.

Operation process requires some organizational measures for the establishment of structures and appointments of persons with clearly defined responsibilities and authority as follows: RIS designates SCP and other individuals within CRSI that will participate in the investigation and resolution of security incidents.

RIS organizes subjects training, the definition of the event and incident, using IPM and reporting events and / or information security incidents.

SCP creates and updates DESI. CRSI investigates the causes of security

incidents and takes measures to eliminate their recurrence. 3. Conducting the process

In the R & D organization will be organized and

will operate CRSI, which will have as main objectives: rapid notification of the problem encountered, controlling the damage and taking all necessary measures to remove the problem in case of security incidents, such as:

Information Security Management Incidents in Research – Development

The Romanian Review Precision Mechanics, Optics & Mechatronics, 2014, No. 45 138

• Disruption of any security measures; • Fires, explosions or floods; • Power surges; • Unauthorized access inside the R & D

organization or system information; • Theft of data, information or equipment; • Disclosure of confidential information; • Breach of confidentiality; • Detection of network port scanning; • Detection of business software viruses; • Compromise of user accounts and passwords; • Corruption of data or information; • Repeated attempts of unauthorized access or use; • External traffic network, or computer system activities unrelated to research and development activities of the organization; • Repeated attempts to send e-mails to internal accounts unknown or nonexistent; • Computer system crashes or services, et cetera. To ensure a quick, effective and organized

response to security incidents, CRSI will define courses of action required to treat each type of incident in part, and operational procedures will be developed. CRSI members will have defined roles that will take priority over normal duties in the organization of research and development. Items included in incident management are:

• Analysis and identification of causes; • Actions to prevent recurrence; •Collecting evidence and surveillance audit reports; • Communication with the staff affected or involved; • Incident escalation, if necessary. For samples and surveillance audits, records will be collected and properly secured to ensure: • That the internal problem is analyzed ; • Using evidence about potential violations of contractual clauses, breach of internal rules or laws and their use in a civil, criminal or disciplinary process; •Ability to negotiate compensation with software vendors or services. For samples collected to be used in case of civil

or criminal legal action will be taken where appropriate, the following rules:

a) Admissibility of evidence - whether evidence may or may not be admitted in court. To ensure admissibility it is necessary that the research and development organization's information system include recognized standard mechanisms for the production of such evidence.

b) The importance of evidence - the quality and completeness of the sample. To ensure this requirement is necessary to ensure strict monitoring of the samples, as follows:

• Printed documents: originals will be kept safe and there will be found who, where, when and who was a witness. Any investigation must provide the original; • Information on electronic storage media: they will make copies of media, to ensure availability. It will be registered the copy action, the process itself will take place in the presence of witnesses. Copy storage media and recording process will be kept secure; • Isolation of the area and collecting evidence, including physical, only by authorized bodies.

c) Adequate evidence to demonstrate that security measures functioned correctly and consistently throughout the sample as in question was stored and processed by the system.

Recovery actions following the occurrence of security incidents and correcting nonconformities will be carefully checked and documented, ensuring that:

• All emergency operations undertaken are documented in detail; • Actions are reported to management at the highest level, to be analyzed in an organized manner; • Integrity of the R & D organization and existing security measures is confirmed as soon as possible; • Only specialized personnel designated and authorized can access functional systems and their data. If in the process of solving the IS it is established

with certainty that it is a non-compliance of the system, which cannot be solved with the resources of the organization, or with as little intervention as involves alteration of the original software in question, the incident will be escalated to the technical assistance of the manufacturer, the terms use licenses or contracts with it.

If the incident is caused by a criminal action, they will gather evidence and / or secure areas where they can obtain conclusive evidence, and will make the necessary arrangements with the competent authorities to complete investigations.

Reporting, evaluation, investigation, settlement and registration will be done according to IS Scheme Incident Handling and logical flow chart shown below, adapted to each category of security incidents

Information Security Management Incidents in Research – Development

The Romanian Review Precision Mechanics, Optics & Mechatronics, 2014, No. 45 139

Logical FlowChart

Figure 1 Incident Handling

STAGE

ACTION

1 A security incident is reported and received by the SCP, which opens FRSI

2

SCP evaluates reporting to determine whether it is a security incident NO YES

SCP forwards the information to be solved by specialized personnel RIS is notified

3

RIS decide whether it is a security incident and determine if immediate action is required NO YES

Reporting is formally recorded in DESI CRSI is notified

4

RSI will determine whether intervention is required CRSI NO YES SCP resolves the incident CRSI is notified

5

RIS determines whether to investigate the incident NO YES Start of recovery Investigation is initiated

Analyze the information

Mobilize

Investigates

Report

Recovery

Prepares and

Observe

Informs and propose

Informs

Formal registration

Formal

i i Yes NO

Collect

Retraining security policies

Report in case of an incident

Solve

3’rd Personnel

Competent authority

Evaluates

RIS

Information Security Management Incidents in Research – Development

The Romanian Review Precision Mechanics, Optics & Mechatronics, 2014, No. 45 140

6

Initiate recovery and investigation The system affected will be immediately isolated from the rest of the company network. If it is a criminal action, the internal network will disconnect the external connections. The decision of disconnection belongs to RIS.

7 Preservation of evidence, if it is decided to RIS It will make a complete system backup, storage media will be labeled and will be securely stored. It will use effective and recognized tools.

STAGE

ACTION

8

Identifying the problem If certain files containing viruses or criminal software can be identified, they will be moved to a safe location. It will use effective and recognized tools. If there are other locations involved, it is possible to gather other information pertinent to the investigation and to solve the problem quickly.

9

Problem Isolation All suspected processes will be stopped and removed from the system. They have removed all files suspected of being infected.

10

System Protection Corrections or modules will be implemented to protect system against future attacks. Once the system was brought in safe running, will test corrections implemented. If possible, virus or criminal software functioning system will be left in isolation, to verify the effectiveness of the solutions discussed.

11

Returning to normal operation Before bringing the system in normal mode affected users and CSR will be notified .

12

Development of FRSI SCP will document compiling FRSI outcome of the investigation, which he will submit to the RIS. RIS will have the DESI incident recording and propose research and development management organization or initiate disciplinary action in court, as appropriate.

13

Tracking Analysis Once an incident has been fully resolved and the systems were restored to full and normal operating state, will conduct a follow-up analysis. All involved will review in a working meeting, the actions taken and lessons learned from treating the incident. Affected policies and procedures will be reviewed and modified if necessary. Where necessary, management will propose the organization of research and development relevant recommendations.

The Institute developed, implemented, maintained and continually improved a documented ISMS within the context of the overall activities and risks of the organization by applying a Deming Cycle "PDCA" model (Figure 2).

Information Security Management Incidents in Research – Development

The Romanian Review Precision Mechanics, Optics & Mechatronics, 2014, No. 45 141

Figure 2– The PDCA Model applied to ISMS processes

4. Conclusions

In conclusion, we note that the major objective of ISMS is the risk management of information security within the context of the overall organization. All these in correlation with the information security management strategy approach allows for the successful design, implementation and operation of the ISMS. 5. References [1] Documentary study on the recommendations of ISO / IEC 27001: 2006 information security management systems; Security techniques; Requirements and ISO

27002: 2008 - Information technology; Security techniques; Code of practice for information security management [2] SR ISO 27.000:2012 – Information Technology; Security techniques; Information security management systems; Overview and vocabulary. [3] SR ISO 27.001:2006 – Information Technology; Security techniques; Information security management systems; Requirements. [4] SR ISO 27.002:2008 – Information Technology; Security techniques; Code of practice for information security management. [5] SR EN 31.010:2011 – Risk Management. Risk Assessment Techniques.

Stakeholders Stakeholders

Elaborate ISMS

Implement, operate ISMS

Maintain, improve ISMS

Monitoring, analyze ISMS

Requirements

and expectations concerning information

Managed