What is a flow?
In QRadar's terms, a flow represents a report, generated/updated minute by minute, of a session between two endpoints connected to network. Rather than the concept of bytes & packets, which flow from 1 host, to the other, and back, the concept of a flow represents the entire session, a count of the bytes and packets generated in the communication, the flags, protocol used, and the time that it is active.
What identifies or defines a unique flow?
QRadar identifies a unique flow based on 5 properties - source ip, source port, destination ip, destination port, and protocol. These 5 properties are used to uniquely identify each "flow" or session in QRadar.
How do different flow sources compare?
QRadar supports multiple sources of flow data, including our own "QRadar Flow Collectors". These devices are normally designed to listen to packet data and are commonly referred to as "internal flow sources". Packet data coming from a network tap device, or a span or mirror port enabled on a physical network switch is monitored by the flow collector, the output of which is often referred to as "qflows" or "flow data". One of the benefits of these "packet" sources is that it allows for layer 7 packet analysis, which can help identify the type of application directly.
Other sources are often referred to as "external flow sources", and are comprised of well known protocols in network monitoring, namely Cisco's Netflow, Juniper's JFlow, the open standard sFlow & Packeteer data formats. These data formats for the most part, do not include payload. However, since they are often coming from border routers, can provide a different level of visibility. For example, Netflow records can provide us with both the router interface that the packets crossed, as well as the ASN record numbers of the originating network. Also, when using "IPFIX", also known as Netflow V9, additional fields that are not parsed into normalized fields, can be placed into the payload area of the data, as name=value pairs, and be used as custom properties, as required.
Why do I see incrementing time stamps every minute on my flows?
As mentioned above, a flow record represents a communication between two endpoints. Often, these sessions last less than a minute (consider a web page you visit and downloads within a few seconds), and then are complete. However, if you consider a session that lasts for an extended period of time - an RDP session to a Windows server; a VOIP call that lasts 25 minutes; a streaming audio session, etc - there must be multiple updates sent into QRadar to report on these ongoing sessions. What happens, is that at the end of each minute, a flow record is sent into the pipeline, with the original "First Packet Time" that the session was seen in, and the "Last Packet Time" is updated to reflect the end of each minute. The byte and packet counts are also reset to zero each minute, so that each minute's worth of bytes & packet counts are what occurred -during- that minute.
The "Storage Time" timestamp refers to when the data is written to disk on the QRadar Processor. This would also 'map" to the time period selected when you create your search. that you choose when selecting a time period to search
What is Flow Direction & Flow Bias?
Flow Direction tells you the direction of the communication. This is used to indicate the source and and destination hosts taking part in the communication.
Flow Bias looks at the amount of data being sent in each direction, and how it's balanced to the local & remote system. Here are the 5 levels of "bias" that qradar will identify, the percentages, and a few sample applications that may show up each bias type
- packets and bytes from the remote side only, no response from local, internal address.
- This could be some remote host, trying to hit address on your network that doesn't respond , doesn't exist, or is blocked at a firewall. A network scan could look like this.
- similar to in only, however a local source address attempting to reach a remote address, but is being blocked or the remote host is unresponsive.
- A common example of this, would be someone on a workstation, that is attempting to reach a port 25 sendmail/smtp server on the internet, but your corporate firewall is blocking it.
- in/outbound byte counts are closer to equal, where more >30% in one direction, and <70% in the other direction.
- A common example of 'near same' communications, could be an instant messaging application, VOIP conversation, or interactive session, such as RDP, ssh, etc.
- any bidirectional flow, with more than 70% of the total bytes outbound to your network
- A example of a mostly-out communication, would be a local web or application server that provides files to end users. A user pulling down a file attachment from a web application would look like a "mostly out" flow.
- any bidirectional flow with more than 70% of the total bytes inbound to your network
- An example of mostly-in communication, would be a end user workstation, connecting to the windows auto-update services, and those update files are pulled down from the autoupdate site for local installation.
- If neither the source or destination ip address are defined in your network, then we classify this as "other" traffic. The reason being, we cannot determine a direction, in or out, when this occurs. For this reason, we cannot assign a bias to the session.
For additional information on flows, please check this Knowledgebase Article on flows. If you have any additional questions, feel free to enter them below, and I'll expand them in this post.