- Welcome to Lesson 22:
Given a Scenario,
Use Data Sources to Support an Investigation.
In this Lesson 22.1,
we're going to focus in on the particular data sources.
Now, incident investigation
often requires analysis of several data sources
in order to draw defensible conclusion,
and even before that, to even just try to figure out
what's going on, what happened.
And we can use vulnerability scan output
to identify weaknesses and potential attack vectors.
We can use log files, which you know I love,
for device, application,
and user specific activity and/or anomalies.
We can use SIEM dashboards for broad overview,
for trend analysis, for alerts, and correlation.
We can use metadata for supporting details,
and we can use packet capture for network traffic.
And just as a refresher,
we've already talked about doing vulnerability scans,
but there are different types of scans, right?
We have network scans, host scans,
wireless scans, application scans, even database scans.
A network scan can identify
possible network security attack points and vulnerabilities.
Our host-based scan gives us visibility
into local host vulnerabilities
as well as configuration settings and patch status.
We can use a wireless vulnerability scan
to identify rogue access points,
or SSID broadcasts, or the use of weak protocols.
We can use application vulnerability scans
to detect software vulnerabilities and configuration issues,
including input and output validation.
And we can even do vulnerability scanning on a database
to identify weak authentication
and security design and configuration issues.
And then there's log data, right?
Log data is so useful.
It's one of the best data sources there is.
So let's look at what we can get from our operating system,
our service and application logs, our network device logs,
our NetFlow logs, even our DNS logs.
So our logs from operating systems, authentication servers,
services, and applications
can really be used to identify which accounts were accessed
and what actions were performed.
Our network device logs
from devices such as firewalls and IDS/IPSs,
can be used to identify ingress and egress access,
connections to malware downloads,
command and control adversaries, that's our CNC,
data exfiltration, and event correlation.
We can use our NetFlows or our network flow information
to find anomalous network activity caused by malware,
data exfiltration, and other malicious acts.
And then DNS events can be collected
to include dynamic updates, zone transfers,
resolution queries.
Now, this information can be really useful
for identifying a DNS-related attack,
such as DDoS or poisoning.
I would also say
going back to operating system service and application,
we wanna think about things like browser logs
and browser history
to be able to create complete timelines of user activity.
Now, maybe you haven't had much experience working with logs
and you really wanna get some hands-on experience.
There is a a free open-source log collection tool
that you could use in your home lab.
It's called the NXLog Community Edition.
Again, free open-source log collection tool.
It's multi-platform,
so it works on Windows and on GNU/Linux.
It's got a really light footprint.
It collects data from most common log sources,
and it has very structured logging.
So in addition to full syslog capability,
it can also parse and generate CSV, a W3C file, a GELF file,
a JASON, XML, or KVP formats,
and it has its own binary data transport format.
So if you wanna download it,
take a look at it, work with it,
you just go out
to nxlog.co/products/nxlog-community-edition.
Now, another data source
is going to come from our log analysis and response tools.
We've talked about all of these already.
So a quick refresher, our SIEM, or SIEM,
which is our Security Information Event Management,
being our automation tool for real-time data capture,
event correlation, analysis, and reporting.
Our Threat Intelligence Platforms.
Our User and Entity Behavior Analytics.
Again, another automation tool
that models the behavior of humans and machines
to identify normal and abnormal behavior.
And then SOAR,
our Security, Orchestration, Automation, and Response
being our automated response tool
that responds to alerts, triages the data,
and takes remediation steps,
but as part of that whole process,
is a really valuable data source for what it's discovering.
And then we have metadata.
Metadata is just data about data.
It's machine-readable and it's searchable.
So example, the content of a photo is the data,
what you see in the picture,
but where the picture was taken,
the date, the time, the direction,
the camera setting, the editing, and the copyright,
those are all metadata extracts, data about the data.
And let me give you an example.
So there's a picture of me, and there is all the metadata.
So that's all the metadata about that particular picture.
Now, there are other types of metadata
that are more useful than pictures of me.
We have file system metadata, we have application metadata,
we have pseudo metadata, and we have email metadata.
The file system metadata is created by the operating system
and it includes file attributes and security permissions.
So for example, file size, location, creation date,
date of last access, date of last write,
whether a file is hidden or compressed or archived.
Application metadata is created by specific applications
and include user and file activity information,
so things like title, author, subject, keywords,
creation and modification date,
time and use, and revision history.
Pseudo metadata is kind called pseudo
'cause it's not really metadata.
It was information that was created by the user
that's hidden or embedded in the document.
So that's things like comments, track changes, formulas,
speaker notes, embedded graphics, and audio and video files.
And then lastly, email metadata,
which is created by our email applications,
generally embedded in the message,
things like the route,
the extracted frequency of contact, and the IP geolocation.
Now, another really useful tool is packet capture.
Packet capture is the process
of intercepting and logging traffic for analysis.
A protocol analyzer, also referred to as a sniffer,
is a tool that we can use
to capture and analyze network packets.
Now, it can also be used to analyze network packets
that have been captured by other devices or other programs.
A port mirror captures network traffic
on one or several ports of a switch
and then forwards a copy of the traffic
to an analysis device.
And a network TAP, which we did talk about earlier,
is a dedicated hardware device
that's inserted between network devices
like a switch and router
and makes copies of the traffic,
and again, forwards to an analysis device.
There are multiple packet capture modes.
First two, normal and promiscuous.
Normal is that the network interface card
only captures frames intended for the interface,
and it does that by filtering by MAC address.
So only if it was intended for that MAC interface,
it says, "Okay, I'll capture it.
Everything else, I'm gonna ignore,"
where promiscuous says the network interface card
is instructed to accept every frame it captures,
even if it's not the intended recipient.
So normal is very myopic.
I'm only capturing what's intended for that interface.
Promiscuous says, "I'm gonna capture everything I can hear,
everything I can listen to."
And then our two other modes
are unfiltered and filtered.
Unfiltered, we are capturing regardless of data elements.
Filtered says our packet capture
is limited to specific data elements.
Packet captures could be incredibly useful.
You just see a quick little illustration here
of doing a packet capture.
I can see all the packets,
I can see the source address, the destination address.
I can see information about the the port and the protocol.
And then if you go all the way down to the bottom,
you can actually see what's in the packet.
Now, in this case, we're not seeing much,
but if it's a clear text packet,
we would see exactly what's in there.
In between, we're seeing things about the routing,
about the IP version,
and other information about the packet itself.
So really, really good data source,
packet capture and analysis, right?
And that brings us to a three-second challenge.
Five challenge questions, three seconds each.
The type of vulnerability scan
that can identify rogue access points.
One, two, three.
It's gonna be a wireless vulnerability scan.
How about number two?
Data about data.
I know you're gonna get this one.
Data about data is, one, two, three.
Metadata.
Number three,
tool used to capture and analyze network packets.
We just looked at it.
One, two, three.
That's gonna be a protocol analyzer or a sniffer.
Number four, an automation tool for real-time data capture,
event correlation, analysis, and reporting.
One, two, three.
And that's gonna be your SIEM.
And lastly, number five, packet capture mode
that instructs a network interface card, or the NIC,
to accept any frame it captures,
even if not the intended recipient.
One, two, three.
That's gonna be promiscuous.
All right, let's do a security-in-action,
and this one's about a suspicious phone call.
One of your colleagues overheard a suspicious phone call
leading you to suspect that an insider
has been collaborating with an external adversary
who's attempting to exfiltrate data.
Your company does not record calls or maintain a transcript.
So is this a dead end
or is there potentially any useful information
that you could use for investigative purposes?
So again, our recap.
Now, one of your colleagues overheard
the suspicious phone call,
and that leads you to suspect that we have an insider
who's been collaborating with an external adversary
who's attempting to exfiltrate data.
But you don't record the calls
and there's no transcript for the calls.
Is there anything,
any information at all that would be potentially useful
that you could use for an investigative purpose?
You get a little hint already about metadata,
so go ahead and think about that, if you want.
Put me on pause, come on back,
and tell me what you could use.
Remember, metadata is data about data, and in this case,
we probably can find some data about the phone call itself.
Now, most phone systems maintain call detail records
known as CDRs, which contain the following metadata.
When the call took place, date, and time,
how long the call lasted in minutes,
who called whom, so source and destination phone numbers,
and what kind of call was made?
Was it inbound, outbound, or toll-free?
Now, this information could prove useful
especially when correlated with other activity.
So don't discount the usefulness about data about data,
which you and I know as metadata.
And that, my friends, is security-in-action.
There's your word cloud, probably a lot of new terms here.
Again, make sure that you're comfortable
and confident in all of them.
And then when you're ready,
well, we only have one lesson in this lesson,
so come on over and we'll do a five-question quiz.