critical information

Critical Information

Table of Contents

Notices ............................................................................................................................................ 2

Critical Information ......................................................................................................................... 2

Needed Information for Incident Handling .................................................................................... 3

Gathering Information -1 ................................................................................................................ 4

Gathering Information -2 ................................................................................................................ 5

Time Frame of Report and Activity ................................................................................................. 6

Example: What Moment in Time Is This? ....................................................................................... 7

Specifying Dates and Times ............................................................................................................ 8

Other Clues and References ......................................................................................................... 10

What Else Do You Need to Identify? ............................................................................................. 11

Incident Tracking System Sample Fields ....................................................................................... 12

of 13

Notices

46Managing CSIRTs© 2020 Carnegie Mellon University

[DISTRIBUTION STATEMENT A] Approved for public release and unlimited distribution.





**025 Our next topic is critical

information. CSIRTs work with

information. And there are many

types. One way to categorize

of 13

information is by importance. Here

we discuss information critical to the

incident management process,

especially detection and triage.

Needed Information for Incident Handling



Needed Information for Incident Handling

What information do you think your team members need to gather to enable them to

effectively handle an incident?

What information do you need to know as a manager to

• prioritize the work load?

• make decisions?

• generate reports?

• stay informed?

**026 What information is needed

by people in different CSIRT

functions? What information will a

CSIRT manager need for these

activities? Prioritizing the workload,

making decisions, generating reports,

and generally staying informed.

There isn't a place in your workbook,

but take some time to briefly write

down what you, as the manager,

need. Now, do the same for incident

handlers in the CISRT.

of 13

Gathering Information -1




The information your CSIRT staff needs to collect to effectively handle an incident

includes

• Who is involved?

• What type of organization do they represent?

• How are they involved?

• What is their role?

• What is the nature of the incident?

• What is the scope of the incident?

• What is the time frame of report and activity?

• Are there other clues and references?

**027 Let's compare your list of

information needed by incident

handlers to the ones here. Who was

involved? Was it a reporter, the

victims, or the attacker? What type of

organization are they in? Was it a

company or other organization, a

CSIRT, an information sharing and

analysis center, or maybe a

concerned citizen acting on their

own?

How were they involved? Was it the

victim, a reporter acting on behalf of

the victim, secondary victims, maybe

even a conspiracy theorist? What

roles do they have, a system

administrator, a CSIRT, perhaps?

What is the nature and scope of the

incident? What is the timeframe? It

happened in the distant past, the

recent past, or now? And anything

else that should be recorded.

of 13





It is also important for your staff to identify any items that are

• missing

• incomplete

• incorrect

• relevant (or irrelevant)

• not supported with evidence

**028 Once the majority of the

information has been gathered, it's

time to take a look at it and look for

anything that is missing, incomplete,

incorrect. Distinguish between

relevant and irrelevant, and, very

importantly, data that's not

supported with any evidence but

merely speculation.

of 13

Time Frame of Report and Activity



Time Frame of Report and Activity

Identify all time and date information.

• email headers

• log file extracts

• other references

What time zones are involved?

• Do not assume the time zone from the domain.

• Different countries use different date/time formats.

Incidents have been reported months/years after the activity took place.

**029 Time is an important data

component of incident response

reporting. Place the times that two

related activities occurred on a

timeline, and you now have valuable

information describing their temporal

relationship. Pinning down the

timeframe of reported activity can be

difficult. Try to capture any time zone

information from email headers and

any supporting log files. Realize that

these cannot always be trusted.

System clocks can be wrong, or an

intruder may have compromised a

system and changed the log data or

even the system clock.

Also, the way that date and

timestamps are written can be a

cause for misinterpretation. Always

ask the site to confirm their date and

time formats. Do not make any

assumptions. Also, double-check at

the logs sent to your team are the

of 13

logs the customer meant to send and

not old logs or more recent ones

without the incident activity that

you're interested in.

You need to consider how to look at

the timestamps and interpret them

correctly. Keep in mind that people in

the U.S. and Europe give days of the

week and months of the year in

reverse order. Remember that a

domain name can be in a single time

zone or can cover the globe and,

therefore, be in many time zones.

Also consider the fact that incidents

can only be reported once they are

detected. Some are detected and

reported months or years after the

intrusion.

Example: What Moment in Time Is This?



Example: What Moment in Time Is This?

02/03/09

12:00 p.m. EST

**030 What date and time does this

represent? Is it February 3rd, 2009,

March 2nd, 2009, March 9th, 2002, or

something else entirely? The date will

of 13

be interpreted differently in different

parts of the world. In the United

States, numeric dates are customarily

listed in order of month, day, and

year, sometimes written as MM/DD/YY,

but in Europe and other parts of world,

it is more common to the list the day

first, followed by the month.

What time is 12PM? Is it midnight, or

is it noon? Some people think it's

midnight, but PM stands for post

meridian, meaning after midday, so

12PM is noon.

What time zone is EST? In North

America, it stands for Eastern

Standard Time, but there is also an

Australian Eastern Standard Time,

which is fifteen hours different. So,

it's best to be specific.

Specifying Dates and Times



Specifying Dates and Times

Avoid ambiguity or confusion when specifying dates and times.

ISO 8601 specifies an International Standard for the numeric representation of date and

time notation.

Format: YYYY-MM-DD

Example: 2020-07-11

**031 Because we deal with

incident response on a global level,

of 13

we must recognize the differences

between formats of date and time

specification. Always try to avoid

ambiguity or confusion when

specifying dates and times. The best

way to do this is look for a standard

to follow. A good one is ISO 8601.

Another good practice is to spell out

the month where that will produce

less confusion.

ISO 8601 specifies an international

standard for the numeric

representation of date and time

notation. It is shown here as

YYYY/MM/DD, or year, month, date.

For example, we have 2020-07-11,

which would be July 11th, 2020. An

advantage to this format is that when

sorted, the dates collate in

chronological order. This is not the

case for the other two popular

formats, where the year is the last or

the least significant field. You might

argue that certain applications know

how to sort dates, and that's all well

and good, but sometimes it's in text

format.

of 13

Other Clues and References



Other Clues and References

Supporting information

• log extracts

• files, programs, malicious code

• other information relating to activity happening at the time of the incident

Identify all reference/tracking numbers.

**032 What other clues and

references should you look for? Are

there other artifacts that were found

on the compromised systems? If so,

can you get a copy of them? Do they

tie into the activity? In what way?

The reporter might be excited,

especially on the phone. Even experts

might describe the attack as one

thing or something new even though

it isn't. Think about how you will

verify the information. No matter

where the data comes from, even if it

is from a trusted source, always

verify and track down the facts.

File hash information is often

supplied as part of the supporting

information. Be sure to check the

hashes of any malicious code sent to

you against several AV databases.

of 13

What Else Do You Need to Identify?



What Else Do You Need to Identify?

In reviewing the incident report, the following questions should be asked:

• Is this a high-priority report?

• Do we agree with the interpretation of the information provided?

• Is there any information that is only speculation?

• Were any assumptions made?

• What assistance is requested and by whom?

• Is there any deadline for response?

Other information to collect may include the

• cost of incident

• value of information or systems recovered

**033 There are many different

questions you will ask while

reviewing an incident. For example,

what is the priority of the request?

Do you agree with the reporter's

interpretation? Be sure to keep an

open mind and examine it from

several sides. Is some of the

information provided speculative?

What assumptions were made? Is

there a deadline for you to respond?

What, if any, assistance are they

requesting?

If they ask for help, clarify just what

they need. If they request something

you cannot provide, have a response

ready and offer contact information

of someone you feel can help. They

may not be asking for help at all, but

providing general information or an

update.

of 13

Incident Tracking System Sample Fields



Incident Tracking System Sample Fields

Reference Numbers

Contact information

Date and time

• of report

• of activity

• of discovery

Description of problem

• category and priority

• overview

• in-depth technical information

• actions taken

• impact and scope

Systems affected

• owner

• criticality and mission

• software and patch versions

Assigned staff

Action items

Staff contacted or interviewed

Supplemental data gathered

Cost of damage

Cost of recovery

Time to resolve

Resolution

**034 Here we have a sample list of

fields that a ticketing system will

store. Reference numbers provide a

unique key for the database used by

the tracking system. Contact

information is vital and should be

gathered consistently. There are

several dates and times. When was it

reported? When did the activity

occur? And when was it discovered?

And interesting number to track is

the difference between the date of

discovery and the date that the

activity actually began. This is called

the dwell time. Sometimes, it can be

surprisingly long, months, sometimes

years.

We need a description of the

problem, including the category and

priority, an overview describing it in

general, as well as in depth technical

information, what actions have been

of 13

taken so far so that they aren't

duplicated, what is the expected

impact and the scope, some

information about the systems

affected, who's the owner or the user

of the system, what is its criticality

and mission, what software patches

and what version are we talking

about, what staff have been assigned

to work on it, what action items have

been done, as well as ones yet

remaining, who has been contacted

so far, any supplemental data

gathered, such as hash values of

malicious code, for example. The cost

of damage, cost of recovery, and

time to resolve are difficult.

Occasionally, you can do something

like if there's a hundred machines to

resolve, and they cost a certain

amount for each one, and they take

so long to handle, and there's a

hundred of them, you can come up

with a rough estimate fairly quickly.

How will it be resolved, or has it been

already?

of 13

critical information

Documents