ITEM #1 reference to retrieval and archiving is removed.

21
ITEM #1 • reference to retrieval and archiving is removed

Transcript of ITEM #1 reference to retrieval and archiving is removed.

ITEM #1

• reference to retrieval and archiving is removed

Item#2

•Justification of FINE – sample generic usage "for reactionary analysis of current intruder activity and proactive identification of trends that can lead to incident prevention"

e.g. in one scenario, CERT-A may have received a report of an incident from one of its constituencies. The attacker in this case is from a constituency of CERT-B. CERT-A will want to communicate all or parts of the incident report to CERT-B. CERT-B will receive the incident report investigate it and probably return all or parts of the investigation results to CERT-A."

Item#2-1

• The designer/developer/implementor of the Exchange Format. • CERTS and other organizations that use implementations of   format

The Audience

Item#3

Move “Goals” to introduction

Item#4

Introduction to the Terminology section

Item#5,6

Ternimology: Damage and Impact

Damage The intended or unintended direct consequence of an attack. E.g. lost data, unusable system, unavailability of services.

Impact The result of the attack in a wider sense. It covers all results of the attack direct and indirect. The impact may be given in financial and/or economic terms.

Item#7

Ternimology:

Computer Security Incident vs Incident Report

Item#8

Ternimology:

Target vs Victim

Drop or keep ?

Item#9

Ternimology:

Attack vs Event

Event => Any occuranceSecurity incident => Adverse eventAttack => Some security incidents

Item#10

Ternimology: Regroup definitions

•CSIRT•Event •Computer/Network Security Incident•Incident Report•Attack•Target •Damage•Impact

Item#11

Ternimology:

Incident

some aspect of computer system or network security is compromised

Item#12

Operational Model Diagram

• Remove reference to Statistics packages• Other Org => collaborators, involved parties, etc.

Item#13

Life Cycle of a report• the report itself evolves. The states: - handling - complete/closed - waiting • the report is updated based on interaction with/ investigation by CSIRTs;• Not one CSIRT can vouch for the full report

Item#14

Life Cycle of a report vs Life cycle of data

The opening or closing of a report does not validate or invalidate the assertions in the report.

Item#15

Move requirements from Operational Model to requirements

Item#16

Requirement # 7.5: definition of “Current Owner”

Item#17

Requirement # 7.6 and 7.8 Additional Reference vs Reference to Advisory

Item#18

Requirement # 7.11 Time reporting

Time will be reported in format that can easily be resolved to UTC and/or localtime.

Item#19

Requirement # 7.14 Move from Content requirements to General requirements

5.6. The Format for Incident report Exchange must have a well defined semantics and provide a standard way for extensibility in terms of addition of components and/or extending the components.

New Requirement

5.7. FINE must allow multilingual reports. And in case there multiple language versions of a component of the report FINE must be provide a way to identify which version is authentic.

An Incident Report may be multilingual i.e. different parts of the Incident Report may use different languages. It is also possible that multiple versions of parts of the report exist, each version in a different language. The versions may not be consistent.

Item#20

Security Considerations: References to sections corrected.