text:
A session table includes one or more records, where each record represents a session. Session record information is stored in various fields, such as key fields, value fields, and timestamp fields. Session information is described as keys and values in order to support query/lookup operations. A session table is associated with a filter, which describes a set of keys that can be used for records in that table. A session table is populated using data contained in security information/events. Rules are created to identify events related to session information, extract the session information, and use the session information to modify a session table. A session table is partitioned so that the number of records in each session table partition is decreased. A session table is processed periodically so that active sessions are moved to the current partition.
This application claims the benefit of U.S. Provisional Application No. 60/862,932, filed Oct. 25, 2006, which is hereby incorporated by reference herein in its entirety.
This invention pertains in general to security information/event management (SIM or SIEM) and in particular to tracking state data (e.g., about a network, a device, or another real-world phenomenon) so that the state data can be used in conjunction with security information/events.
The field of security information/event management (SIM or SIEM) is generally concerned with 1) collecting data from networks and networked devices that reflects network activity and/or operation of the devices and 2) analyzing the data to enhance security. For example, the data can be analyzed to identify an attack on the network or a networked device and determine which user or machine is responsible. If the attack is ongoing, a countermeasure can be performed to thwart the attack or mitigate the damage caused by the attack. The data that is collected usually originates in a message (such as an event, alert, or alarm) or an entry in a log file, which is generated by a networked device. Exemplary networked devices include firewalls, intrusion detection systems, and servers. The message or entry usually includes a timestamp that reflects when the network activity occurred.
While it is possible to identify and investigate an attack using only the collected data, it is often helpful to have additional information such as the state of the network. A network's state includes, for example, the various devices in the network and how the devices are connected (e.g., the network's topology). Each device also has a state. This state includes various attributes such as, for example, a hardware attribute (e.g., a Media Access Control (MAC) address of the device), a logical attribute (e.g., an Internet Protocol (IP) address assigned to the device), an ownership attribute (e.g., a person or entity who owns the device), a geographical attribute (e.g., a physical location of the device), a software attribute (e.g., an operating system installed on the device), a login attribute (e.g., a user who is currently logged in to the device), a process attribute (e.g., a process that is currently executing on the device), and a network attribute (e.g., an active network connection of the device).
Consider a message that has been identified as being part of an attack. Information in the message might indicate the source device of the attack (e.g., by the device's IP address). This IP address can then be used to identify other messages that are part of the same attack. But it would also be helpful to know to which device the IP address is assigned (e.g., as indicated by the device's MAC address or hostname). If the device/IP address pair is known, then any mention of the IP address can be traced back to the device. Also, if the users logged in to that device are known, then the device can be traced back to the users. If the users' roles are known, then the users can be traced back to their roles, and the roles can be considered in conjunction with the messages that were received and the actions that the messages describe.
Unfortunately, it is not easy to determine the state of the network at any given time. This is because the state is not constant—it changes over time. In particular, each device's state changes over time. For example, the IP address assigned to a device can change over time due to different Dynamic Host Configuration Protocol (DHCP) leases, different Virtual Private Networks (VPNs) being used, or Network Address Translation (NAT). As another example, the users logged in to a device can change over time as various people log in and log out. Thus, it is helpful to know not only the current state of the network but also the past state(s) of the network. Since the attributes of a particular device can change, knowing the correct attributes at any given point in time is helpful in order to correlate events involving the same machine or user.
Consider a user on a first machine trying to log in to a second machine. If the user tries to log in ten times within five minutes and fails each time, then this occurrence should be flagged for review because it might signify an attack. Assume that each failed login generates a message that includes the IP address of the first machine. If the first machine had the same IP address for all ten failed logins, then an attack would be identified. On the other hand, if the first machine changed IP addresses during the attack, then some messages would indicate a first IP address and other messages would indicate a second IP address. Since neither IP address was used for all ten failed logins, nothing would be flagged for review. This is called a false negative.
In this situation, it would be helpful to know the state of the network at the time of the possible attack. For example, at the time of each failed login message, it would be helpful to know to which device (e.g., based on MAC address or hostname) the IP address was assigned. If this were known, then even though the failed logins came from different IP addresses, the IP addresses could be traced back to the same device and an attack could be identified. This is made possible by the fact that MAC addresses and hostnames change less frequently than IP addresses. In other words, IP addresses are more transient than MAC addresses and hostnames.
Note that changing IP addresses can also cause false alarms. Along the lines of the example above, consider four failed logins from one source device and six failed logins from another source device, each occurring within a five-minute time span and directed at the same machine. Although the source devices are different, and they never had the same IP address simultaneously, each device had the same IP address at the time that device caused a failed login. Since this same IP address was present in all ten failed login messages, this occurrence would be flagged for review. This is called a false positive.
What is needed is a way to maintain and query changing state data in an efficient manner so that the data can be used in real-time in conjunction with security information/events.
A network's state changes over time. In particular, each device's state changes over time. If a state attribute (such as Internet Protocol (IP) address) changes over time, then a particular value of that attribute is valid for a particular time period, which we will refer to as a “session.” In general, a session can be thought of as an association between two entities (e.g., a device and an IP address or a person and an asset) that is valid for a particular time period.
Session information can be used by itself or in conjunction with other information (e.g., other datastores or security information/events collected from networks and/or networked devices). Session information can be used for correlation, auditing, associating actions with users, associating users with business roles, identifying devices, enforcing company policies based on users and/or roles, filtering events, reporting, etc. For example, session information can be correlated with other information according to rules to identify and/or investigate attacks or anomalous behavior. Security information/events include timestamps that reflect when network activity occurred. When these events are correlated with session information, the session information reflects the session that was valid at the time of the timestamps.
For each type of session, a session table is maintained. A session table includes one or more records, where each record represents a session. Session record information is stored in various fields. Together, these fields comprise a schema for the session information. Each schema includes three types of fields: key fields, value fields, and timestamp fields. Session information is described as keys and values in order to support query/lookup operations.
A session table can be associated with a filter. The filter describes a set of conditions that defines the data that is managed by the session table (e.g., a set of keys that can be used for records in that table). Using a filter decreases the time necessary to evaluate an event against available session information because unnecessary lookups of session information are eliminated.
One way to populate a session table is to use data contained in security information/events. Rules are created to identify events related to session information, extract the session information, and use the session information to modify a session table (e.g., by creating, modifying, or terminating a session record). Relying on events to start and end sessions can result in an inaccurate session table. These problems can be addressed by using rules to implicitly determine session boundaries based on events that have been received.
There can be a delay between the time a session starts or ends and the time that this information is entered into a session table. Sometimes the delay is small. In this situation, it can be helpful to wait before attempting to correlate a security event with that session data. Sometimes the delay is large. In this situation, session information might arrive “late,” in that correlation has already been attempted between session information of that time interval and various security events. In one embodiment, in this situation, correlation is performed again to take advantage of the session information that was received late.
A session table is partitioned so that the number of records in each session table partition is decreased. This decreases the amount of resources required to perform each query. A session table is processed periodically so that active sessions are moved to the current partition. This feature, which is called “session rollup,” guarantees that if a session is active, its record will be located in the current partition. In other words, live session information is “rolled up” from a previous partition to the current partition so that the information is readily available in the current partition. Session rollup decreases the amount of resources required to access an active session because only the current partition need be queried.
FIG. 1 shows exemplary schemas for different types of session information.
Although the present system will be discussed with reference to various illustrated examples, these examples should not be read to limit the broader spirit and scope of the present invention. For example, the examples presented herein describe security information/events, session tables, and records, which are but one embodiment of the present invention. The general concepts and reach of the present invention are much broader and may extend to any computer-based or network-based security system. Also, examples of the messages that may be passed to and from the components of the system and the data schemas that may be used by components of the system are given in an attempt to further describe the present invention, but are not meant to be all-inclusive examples and should not be regarded as such.
As explained above, a network's state is not constant—it changes over time. In particular, each device's state changes over time. If a state attribute (such as Internet Protocol (IP) address) changes over time, then a particular value of that attribute is valid for a particular time period, which we will refer to as a “session.” Information associated with a session (“session information”) includes, for example, a first timestamp that indicates the start of the session, a second timestamp that indicates the end of the session (if the session has ended), a third timestamp that indicates the creation of a session record (discussed below), and one or more pieces of data that are valid during that session.
Consider a device that has received an IP address via a Dynamic Host Configuration Protocol (DHCP) lease. The one or more pieces of data might include a) an IP address (and, if the IP address is not globally unique, a network zone that contains the IP address) and b) an indication of the device to which the IP address was assigned (e.g., the device's hostname and/or Media Access Control (MAC) address). (A network zone is a network segment. A label identifies a network zone and is used to distinguish private address spaces from one another.) Similarly, consider a device that has received an IP address via a Virtual Private Network (VPN) login. In addition to (a) and (b) above, the one or more pieces of data might include a username that was used to initiate the VPN login. As another example, consider a device that has been characterized by an IP address via Network Address Translation (NAT). Here, the one or more pieces of data might include a) an IP address (and, if the IP address is not globally unique, a network zone that contains the IP address), b) an indication of the device to which the IP address was assigned via translation (e.g., the device's hostname and/or actual IP address and source port).
Other device state attributes can also be modeled using sessions. Consider a first device (“destination device”) that allows other users to log in to it from a second device (“source device”). The one or more pieces of data might include a) an IP address (and, possibly, network zone) of the destination device, b) an indication of the source device (e.g., the source device's hostname and/or IP address and network zone), and c) other login information (e.g., the username used at the source machine and/or the username used at the destination machine).
While the session information described above is related to networking, many different types of information are valid for a particular time period and thus can be modeled using sessions. For example, information about the physical world can be modeled using sessions. An asset (such as a computer) can be owned by or assigned to a person or entity. A person can be present in a physical location. A phone number can be assigned to a person. Each of these states is temporary and, thus, can be modeled using a session.
In general, a session can be thought of as an association between two entities (e.g., a device and an IP address or a person and an asset) that is valid for a particular time period. Session information can be used by itself or in conjunction with other information (e.g., other datastores or security information/events collected from networks and/or networked devices). Session information can be used for correlation, auditing, associating actions with users, associating users with business roles, identifying devices, enforcing company policies based on users and/or roles, filtering events, reporting, etc. For example, if employees are required to swipe their ID cards when they enter and leave the office, then the following reports can be generated: average number of hours spent by employees at work and time pattern of employees entering and leaving the office.
a) Identifying events associated with a particular person—A device/person session table determines which device is owned by or assigned to the person. A login session table determines which devices have been logged in to by the person's device and which devices have been logged in to from those devices, etc. Events originating from those devices are identified.
b) Identifying a login that was initiated from a location other than the user's location—A login session table determines which usernames and source devices have logged in to a target device. A datastore determines which real people correspond to the usernames and where the source devices are located. A location/person session table determines where the real people are located (e.g., based on recent swipes of a badge or ID card to access a room or building). The real people's locations are compared to the source devices' locations.
c) Determining a moving average of attacks generated from machines accessing the network via VPN—IP addresses contained in messages related to attacks are compared to IP addresses in a VPN session table.
d) Determining a moving average of attacks generated from users accessing the network via VPN—IP addresses contained in messages related to attacks are compared to IP addresses in a VPN session table. Matching usernames in the records are determined.
e) Identifying users logged into a machine at the time the machine initiated an attack—A message related to an attack includes an indication of the device that initiated the attack and a timestamp indicating the initiation of the attack. A login session table determines which usernames were logged in to that device at that time.
In one embodiment, a rule comprises a set of simple or complex conditions optionally combined with other constructs such as aggregation, groupings, and triggers. A rule can be used in many ways, such as: to evaluate incoming events for specific conditions and patterns; to correlate information from different events using rule correlation as well as other constructs like active lists, session lists, and threat level calculations; to infer meaning about significance of events; and to initiate real-time actions in response to events.
Correlations and rules are further described in U.S. application Ser. No. 10/308,415, filed Dec. 2, 2002, which is hereby incorporated by reference herein in its entirety.
For each type of session, a session table is maintained. For example, one session table maintains session information related to devices and IP addresses while another session table contains session information related to people and assets. A session table includes one or more records, where each record represents a session. For example, a device/IP address session would describe a time period for which a particular device was assigned a particular IP address. This record would be stored in a device/IP address session table. In one embodiment, a session table is similar to a Session List, which is a feature of the ArcSigh™ Enterprise Security Manager (ESM) 4.0 (available from ArcSight, Inc. of Cupertino, Calif.).
Recall that session information includes, for example, a first timestamp that indicates the start of the session, a second timestamp that indicates the end of the session (if the session has ended), a third timestamp that indicates the creation of a session record, and one or more pieces of data that are valid during that session. This information is stored in a session record. The third timestamp indicates when the session record was created. Note that network latency might cause a gap in time between the start of a session and the creation of the record corresponding to that session.
Session record information is stored in various fields. Together, these fields comprise a schema for the session information. Different types of session information can have different schemas. FIG. 1 shows exemplary schemas for different types of session information. The illustrated schemas are DHCP, VPN, NAT, Login, and Asset Ownership. In FIG. 1, each rectangle represents a field.
Each schema includes three types of fields: key fields, value fields, and timestamp fields. In one embodiment, session information is described as keys and values in order to support query/lookup operations. (Query operations are used to access information in the session table and are further discussed below.) In this embodiment, each session table would specify one or more fields of a record to be used as keys (the “key field(s)”). One or more other fields of a record would be used as values (“value field(s)”). For example, in a device/IP address session table, the IP address (and, possibly, network zone) can be used as a key, and other session information (e.g., hostname and MAC address) can be used as the values.
Timestamp fields, which include the Start Time field, End Time field, and Creation Time field, each contain a timestamp as described above (unless the session has not ended, in which case the End Time field would be empty). The Start Time field value and End Time field value are used to identify a valid session for a given key at any given instance of time. For example, given a key and a particular timestamp, if that key maps to several sets of value fields, the appropriate set of value fields is the one whose Start Time and End Time surround the timestamp.
FIG. 1 shows the key field(s), timestamp field(s), and value field(s) for each schema. The indication of one or more key fields is also part of the session information schema.
In this way, the session table acts as a key-value mapping that maps or binds keys to values. For example, a session query would contain one or more keys (“query keys”), and the query result would contain one or more values that were bound to the one or more keys. Since a session can be thought of as an association between two entities, one entity is represented by the key, and the other entity is represented by the value.
The information contained in some fields can be identical among different sessions (and, therefore, among different records). For example, if a device is assigned a first IP address one day and a second IP address another day, each session record will contain identical information regarding the device (e.g., the device's MAC address or hostname). Similarly, if an IP address is assigned to a first device one day and a second device another day, each session record will contain identical information regarding the IP address. If two records contain identical field information and this field information determines the key, then that one key needs to map to two different sets of information (one set for each session). This functionality can be implemented by, for example, putting the sets of session information in a list and having the key's value be that list. The Start Time field value and End Time field value are used to identify which set of session information is valid at a given instance of time, as described above. In one embodiment, the sets of session information are sorted within the list according to each session's start time. This decreases the time necessary to perform a lookup.
In one embodiment, a session table is implemented as a hashmap, and the key that is used for a lookup is a hashcode that is determined based on the hashcodes of all of the key fields. In this embodiment, the hashmap key can be thought of as a tuple of key field values.
The hashmap value is a data structure (“SessionIntervalDataStructure”) that represents a list of one or more sets of session information. This is similar to the chained hash table technique. In one embodiment, the entries in the data structure (each of which is a set of session information) are managed using an interval tree. An interval tree is an ordered tree data structure used to hold intervals. An interval tree enables efficient determination of all intervals that overlap with a given interval or point.
Here, the interval of an entry uses that session's start time and end time as endpoints. In order to correlate a security event with information in a session table, the relevant session must first be identified. In one embodiment, the event's end time is used to match the interval to select an appropriate entry (session) applicable to the security event. If an entry is open-ended (i.e., the session has not yet terminated), a maximum time is used as an interval end time. The data structure used to represent the interval tree can vary. In one embodiment, if the number of expected entries per table and key tuple is limited, an array-based implementation is used.
The memory required to store a session table is proportional to the number of records in the table. In other words, the memory requirement grows in O(n) where n is the number of records loaded in memory for the session table. Regarding lookup time, if m is the number of unique keys (based on the key field tuple) in the session table and p is the average number of entries per unique key, then the time required to perform a lookup is O(log p). Here, m*p=O(n).
Common operations that are performed on a session table and their time order complexity are as follows: Querying a session value field (e.g., to correlate with a given event) is O(log p). Updating the end time of a record is O(log p). Inserting a new record is O(log p). These low time order complexities enable session tables to be queried and maintained in real-time so that the session information is available in real-time to be used for correlation, etc.
In order to retrieve session information that is applicable to a particular security event, a dependent variable function is defined. In one embodiment, this definition includes a name for the dependent variable, a session table to be used to retrieve the session information, and a mapping of the event's fields to the key fields in the session table. Based on this definition, corresponding entries are identified in the session table and made available to be used in correlation.
Dependent variables can be chained in order to access session information from different sources. A user can specify not only multiple data sources in which to look for information but also the order in which these data sources should be used. For example, a user can specify that if DHCP information and VPN information are both available, the MAC address can be retrieved from either and then combined with information from disparate sources to be used in correlation.
In one embodiment, a session table can be associated with a filter. The filter describes a set of conditions that defines the data that is managed by the session table (e.g., a set of keys that can be used for records in that table). For example, if the table stores DHCP information and the keys are IP addresses, then the filter can describe a range of IP addresses (e.g., the IP addresses that can be assigned by the DHCP server). Using a filter decreases the time necessary to evaluate an event against available session information because unnecessary lookups of session information are eliminated. A filter avoids querying a session table for an event for which session information is not available. In this way, a filter acts as a gate-keeper for queries directed to a table.
In one embodiment, a filter is implemented as follows: An event is identified for which a session table lookup is desired. Based on data stored within the event, the query key is determined. Before the lookup is performed, the query key is tested against that table's filter. If the key passes the test, then the desired data might be stored in the table and the lookup is performed. If the key fails the test (e.g., if the IP address key is not within the filter's range of IP addresses), then the desired data is not stored in the table and the lookup is not performed.
A session table can be populated with data in various ways. One way is to import data from a file such as an archives The file, which can be located on any networked device, can contain any type of information in any format (e.g., comma-separated values (CSV) format). For example, the file may have been output by a datastore that contains information that is desired to be correlated with security information/events. Consider a database that contains Human Resources (HR) information such as employees and their business roles within an organization. Exporting this HR data from the database to a file and then importing the file into a session table will make the data available in real-time for correlation, etc. This data can be used, for example, to enforce network access policies based on a user's business role rather than based on a device or an IP address.
Another way to populate a session table is to use directory services to retrieve data from datastores. These directory services can be accessed via various protocols such as Lightweight Directory Access Protocol (LDAP) or X.500.
Yet another way is to use one or more software agents (such as SmartConnectors from ArcSight, Inc.) to send the desired data in the form of events. Then, one or more rules can be used to process the events. Specifically, the rules can extract session data from the events and use this data to populate session tables.
Another way is to enter the session data directly into the data structure underlying the session list. For example, if the session list is stored in a database (see below), then the session data can be entered directly into the database.
Yet another way to populate a session table is to use data contained in security information/events. Rules are created to identify events related to session information, extract the session information, and use the session information to modify a session table (e.g., by creating, modifying, or terminating a session record). The rules can be run on events as the events occur (“live mode”) or on past events that have been stored (“batch mode”).
One example of populating a session table based on events is DHCP snooping, where DHCP information (e.g., lease assignment events) is used to create a DHCP session table. For example, a DHCP acknowledgment message causes a rule to create and start a session (i.e., add a record to the DHCP session table). A DHCP release message causes a rule to terminate a session (i.e., add an end time to an existing record in the DHCP session table).
Relying on events to start and end sessions can result in an inaccurate session table. For example, network latency can cause events to arrive late and/or out-of-order. Also, some events might never arrive, such as DHCP release messages, which are optional. These problems can be addressed by using rules to implicitly determine session boundaries based on events that have been received. In one embodiment, session boundaries are implicitly determined for session information that is non-overlapping.
Session information can be either overlapping or non-overlapping, based on the type of the information involved. If session information is non-overlapping, this means that at any instance of time, for a given key, only one valid session exists (and, thus, only one valid session record exists). DHCP information is one example of non-overlapping session information. This is because for a given network zone, an IP address (key) can be assigned by a DHCP server to only one device (value) at any given instance of time. This assignment can change later to another device, but by that time the earlier device would have released the same IP address. VPN information is another example of non-overlapping session information. On a given network zone, VPN software assigns an IP address to only one user/machine at any given instance of time, based on its configuration.
If session information is overlapping, this means that at any instance of time, for a given key, multiple valid sessions can exist (and, thus, multiple valid session records can exist). Login information is one example of overlapping session information. This is because for a given network zone, an IP address (key) can be logged in to by multiple users (value) at any given instance of time.
The overlapping/non-overlapping nature of session information affects what types of values are returned when a session table is queried. For example, if a session table contains non-overlapping information, then a successful lookup based on a key/timestamp pair will return only one set of session information. On the other hand, if a session table contains overlapping information, then a successful lookup based on a key/timestamp pair might return multiple sets of session information (e.g., a list whose entries are sets of session information, as described above).
Implicit determination of session boundaries comes in two forms: implicit session termination and implicit session splitting. Implicit session termination comprises determining that an existing session has ended without having actually received a session termination event. When a session start event arrives that contains a key for an existing active session, the previous session for that key is terminated and a new session is created and started using the information contained in the session start event. (An active session, also referred to as a “live” or “ongoing” session, is a session whose record does not contain an end time timestamp.) Arriving session start events of this type commonly occur with DHCP session information because DHCP servers usually don't log lease expiration events.
In one embodiment, implicit session termination proceeds as follows: When a session start event arrives, its key fields are determined and used to generate a hashcode. The relevant session table is checked for a pre-existing active session corresponding to that hashcode. If a pre-existing active session is found, then this session must have terminated, since the session information cannot overlap. The pre-existing session is terminated by putting a timestamp in the end time field of the session record. A new session is created (corresponding to the same hashcode) and started using the information in the session start event.
Example of implicit session termination—According to a record in a session table, an IP address in a given network zone (key) is assigned to a particular hostname and MAC address (192.168.0.1, Internal Zone 1)=>(hostname1, 11:11:11:11:11:11) at Oct. 12, 2007 10 PM. At Oct. 12, 2007 11 PM, a session start event arrives that maps the same IP address in the same zone (key) to a different device (192.168.0.1, Internal Zone 1)=>(hostname2, 22:22:22:22:22:22). The session start event will cause the first session to be terminated (with an end time of Oct. 12, 2007 11 PM) and a second session to be created and started (with a start time of Oct. 12, 2007 11 PM).
Implicit session splitting comes in two forms. In the first form, a session termination event arrives for a session that has already terminated. If the session termination time in the newly-arrived event is earlier than the end time currently stored in the corresponding session record, the new session termination time is stored in the session record. This scenario can occur if, for example, the previous session termination time was derived using implicit session termination.
Example of implicit session splitting (first form)−According to a record in a session table, a session terminated Oct. 12, 2007 11 PM. A session termination event arrives that corresponds to this session record and indicates a termination time of Oct. 12, 2007 10:30 PM. The end time in the session record is changed from Oct. 12, 2007 11 PM to Oct. 12, 2007 10:30 PM.
In the second form of implicit session splitting, a session start event or session end event arrives whose timestamp corresponds to an existing session. The existing session can be an ongoing session or a terminated session. If the value stored in the existing session differs from the value stored in the event, then the existing session is split, and a new session is created and started in the middle.
Example of implicit session splitting (second form)−According to a session table, a session S1 starts at Jan. 1, 2008 1 PM and ends at Jan. 1, 2008 10 PM, and a session S2 starts at Jan. 1, 2008 11 PM and is active. An event arrives that indicates the existence of a session S3 starting at Jan. 1, 2008 6 PM. Session S1 is split so that it starts at Jan. 1, 2008 1 PM and ends at Jan. 1, 2008 6 PM. Session S3 is created so that it starts at Jan. 1, 2008 6 PM and ends at Jan. 1, 2008 11 PM. Session S2 remains as an active session that starts at Jan. 1, 2008 11 PM.
There can be a delay between the time a session starts or ends and the time that this information is entered into a session table. Sometimes the delay is small. For example, if a session start event is generated by a device in Japan, it can take a second or more for that event to be collected and processed in the United States. In this situation, it can be helpful to wait before attempting to correlate a security event with that session data. If the correlation is attempted too soon, the session data might be stale or might not even exist. Waiting to correlate a security event is referred to as “parking” the security event. In one embodiment, if session data exists, a security event is parked for a minimum wait time. The hope is that the session data will be updated (if necessary) during that wait time and then be available for correlation. In one embodiment, if session data does not exist, a security event is parked for a maximum wait time. The hope is that the session data will be loaded during that wait time and then be available for correlation.
Sometimes the delay is large. For example, session information from an employee badging system might be imported nightly (e.g., in a batch process) rather than loaded in real-time (e.g., as badge swipes occur). In these situations, session information might arrive “late,” in that correlation has already been attempted between session information of that time interval and various security events. In one embodiment, in this situation, correlation is performed again to take advantage of the session information that was received late. For example, a correlation rule can be re-run on a window of past security events (e.g., the security events that were received in the past two hours). The circumstances under which a correlation rule should be re-run (and which events it should be re-run on) are configurable.
As discussed above, session data is stored in session tables. Specifically, each type of session data is stored in a separate session table (e.g., one session table for DHCP session data and one session table for login session data). In order for session data to be referred to later, the session tables are stored in persistent, non-volatile storage such as a hard drive. In one embodiment, the session tables are stored in a database such as a relational database.
The number of records in a session table can increase significantly over time, leading to very large session tables. Performing a query on a large table is much more expensive (in terms of computer resources such as processor time) than performing a query on a small table. In one embodiment, a session table is partitioned so that the number of records in each session table partition is decreased. This decreases the amount of resources required to perform each query.
In one embodiment, the session table is partitioned based on session start time. Recall that each record in a session table includes a start time timestamp. The value of this timestamp determines in which partition the record is stored. In one embodiment, each partition represents a 24-hour period. For example, a first partition represents Jan. 1, 2007 12:00 AM to Jan. 1, 2007 11:59 PM and a second partition represents Jan. 2, 2007 12:00 AM to Jan. 2, 2007 11:59 PM. In this embodiment, one year's worth of session data would be stored in 365 partitions rather than in one huge session table.
Correlation can be done in either batch mode or in real-time. In batch mode, when security information/events are received, they are stored. Later, the stored security information/events are correlated with the session information—specifically, the session information that was valid at the timestamps of the events.
In real-time mode, when security information/events are received, they are correlated with the session information in real-time or near real-time. In order for this correlation to take place in real-time, the session data must be maintained in real-time and must also support real-time querying. This is very difficult to achieve, since thousands of events are generated per minute, and each event can include one or more references to session information (e.g., one or more IP addresses to be used to determine the MAC addresses to which those IP addresses have been assigned or one or more hostnames to be used to determine the users who are logged in to that host). For example, an event rate of 5,000 events/second and 2 session references/event results in 10,000 session references/second.
In one embodiment, a portion of a session table is also maintained in volatile memory (e.g., a cache or Random Access Memory (RAM)) in order to support faster access for updating and/or querying. For example, if the session table is partitioned in long-term storage, then the current partition (or a portion thereof) is also stored in volatile memory. In general, the portion of the session table in volatile memory will include sessions that are active and, possibly, sessions that were recently terminated (e.g., within the past ten minutes). Since most real-time updates and queries will concern active sessions and recently-terminated sessions, storing these sessions in volatile memory will decrease the amount of resources required to perform each update and query. In one embodiment, the portion of the session table that is maintained in volatile memory is initially loaded from long-term storage. The number of records to be stored in volatile memory is configurable.
In order to maintain the consistency of the session table in long-term storage, updates are collected and periodically applied to the session table as a batch operation. For example, updates are collected over a one-minute period and then applied to the session table in long-term storage as a batch operation.
Even if a session table has been partitioned, it can still be expensive to locate a particular session. For example, if a session's start time is not known, then each partition must be searched until the session is found. In one embodiment, a session table is processed periodically so that active sessions are moved to the current partition. This feature, which is called “session rollup,” guarantees that if a session is active, its record will be located in the current partition. In other words, live session information is “rolled up” from a previous partition to the current partition so that the information is readily available in the current partition (which is stored in volatile memory, as described above). Session rollup decreases the amount of resources required to access an active session because only the current partition need be queried.
After session rollup, past partitions will contain only terminated sessions (i.e., sessions whose records contain end time timestamps). Since past partitions do not contain live session data, it is easier to delete or archive these partitions.
In one embodiment, session rollup is implemented via a scheduled task. The task is scheduled to run periodically (e.g., at each partition boundary if the partition is based on time). The specific period is configurable. If a session extends from one partition to another (e.g., because the partitions are based on date, and because the session is live on two different dates), the session is split into multiple sessions based on partition boundaries, and each session is stored in a different partition.
For example, consider a first partition that represents Jan. 1, 2007 12:00 AM to Jan. 1, 2007 11:59 PM and a second partition that represents Jan. 2, 2007 12:00 AM to Jan. 2, 2007 11:59 PM. A session starts Jan. 1, 2007 11:00 PM and ends Jan. 2, 2007 1 AM. Session rollup will divide the session into two sessions: a) Jan. 1, 2007 11:00 PM to Jan. 1, 2007 11:59 PM and b) Jan. 2, 2007 12:00 AM to Jan. 2, 2007 1 AM. Session (a) will be stored in the first partition as a terminated session, and session (b) will be stored in the second partition (also as a terminated session). If the session concerns DHCP information, a given IP address and network zone will match to the same hostname and MAC address for all the events that have timestamps between Jan. 1, 2007 11:00 PM and Jan. 2, 2007 1 AM, regardless of the session splitting.
As another example, consider a session that starts Oct. 1, 2007 2 PM and is ongoing as of Oct. 5, 2007. Performing session rollup on Oct. 5, 2007 will split the session into five sessions (one for October 1, one for October 2, one for October 3, one for October 4, and one for October 5). The first four sessions stored in their respective partitions as terminated, and the fifth session (October 5) will be stored in the active partition as ongoing.
In one embodiment, session rollup includes: Of the sessions that started since the last session rollup (or the sessions that started during the previous partition, whichever is earlier), determining which sessions are active. For each of these sessions, splitting the session into multiple sessions based on the partition boundary. For a terminated portion of a session, adding that portion to a past partition so that it ends at the partition boundary time. For an ongoing portion of a session, adding that portion to the current partition so that it begins at the partition boundary time.
In order to determine the length of an entire session, the split sessions can be combined. Specifically, if a session ends at a partition boundary time and the next partition includes a session with the same key and values that starts at the partition boundary time, then these sessions correspond to one another. The durations of these sessions can be combined to determine the duration of the entire (non-split) session.
In one embodiment, when a session is split into multiple session portions, each session portion is annotated in some way to indicate that it is part of a larger session. This helps identify session portions when determining the duration of an entire (non-split) session. For example, a flag is added to the record for each session portion. As another example, the start time of the overall (non-split) session is added to the record for each session portion. In this example, corresponding session portions would have identical start times for the overall session in addition to identical keys and values.
The above description is included to illustrate the operation of the embodiments and is not meant to limit the scope of the invention. The scope of the invention is to be limited only by the following claims. From the above discussion, many variations will be apparent to one skilled in the relevant art that would yet be encompassed by the spirit and scope of the invention.
in response to a determination that an active session in the session table corresponds to the hash code, terminating, by the physical processor implementing the machine readable instructions, the active session and creating a new session in the session table in the active session partition to record the information of the event.
2. The method of claim 1, wherein terminating the active session comprises inserting, by the physical processor implementing the machine readable instructions, a timestamp in an end-time field of the active session.
3. The method of claim 1, wherein the query key comprises an Internet Protocol (IP) address.
creating, by the physical processor implementing the machine readable instructions, a new session in the session table for a new event associated with a device connected to a network, wherein the created session includes a hostname or a Media Access Control (MAC) address of the device.
inserting, by the physical processor implementing the machine readable instructions, the start time in a first timestamp field for the new session.
inserting, by the physical processor implementing the machine readable instructions, the end time in a second timestamp field for the new session.
determining, by the physical processor implementing the machine readable instructions, the end time from the session termination event.
8. The method of claim 1, wherein querying the session table comprises determining, by the physical processor implementing the machine readable instructions, a session in the session table having a start time earlier than the timestamp of the event and an end time later than the timestamp of the event.
9. The method of claim 1, wherein querying the session table comprises, by the physical processor implementing the machine readable instructions, testing the hash code against a filter associated with the session table.
in response to determining the event is associated with the batch process, querying, by the physical processor implementing the machine readable instructions, the session table in the active session partition after the batch process.
11. The method of claim 10, wherein querying the session table comprises querying, by the physical processor implementing the machine readable instructions, the session table in the active session partition before and after the batch process.
determining, by the physical processor implementing the machine readable instructions, whether an active session in the session table exists in the session table based on the hash code and a timestamp field of each session in the session table that indicates whether the session is terminated.
querying, by the physical processor implementing the machine readable instructions, the active session partition using the hash code.
in response to a determination that an active session in the session table in the active session partition corresponds to the hash code, terminate the active session and create a new session in the session table in the active session partition to record the information of the event.
Australia Office Action dated Jun. 24, 2011 for serial No. 2007308828 filed Oct. 25, 2007 (3 pages).
Benjamin Fabian, Physical Intrusion Detection Using RFID: Trends, Technology, Problems (Presentation Slides), First German Informatics Society (GI) Special Interest Group (SIG) Intrusion Detection and Response (SIDAR) Graduate Workshop on Reactive Security (SPRING), Institute of Information Systems, HU Berlin, Jul. 2006, pp. 1-15 [online], Retrieved on Mar. 17, 2008, Retrieved from the URL: <https://eldorado.uni-dortmund.de/bitstream/2003/22613/1/Spring-1-Benjamin-Fabian.pdf>.
Benjamin Fabian, Physical Intrusion Detection Using RFID: Trends, Technology, Problems (Presentation Slides), First German Informatics Society (GI) Special Interest Group (SIG) Intrusion Detection and Response (SIDAR) Graduate Workshop on Reactive Security (SPRING), Institute of Information Systems, HU Berlin, Jul. 2006, pp. 1-15 [online], Retrieved on Mar. 17, 2008, Retrieved from the URL: <https://eldorado.uni-dortmund.de/bitstream/2003/22613/1/Spring-1—Benjamin—Fabian.pdf>.
Canada Office Action dated Nov. 19, 2011 for serial No. 2,660,847 filed Oct. 25, 2007 (3 pages).
Cisco Adaptive Threat Defense for Education Networks, 2005, pp. 1-10, [online], Retrieved on Mar. 17, 2008, retrieved from the URL: <http://www.cisco.com/web/strategy/docs/higher-CampusSecure-defense-WP.pdf>.
Cisco Adaptive Threat Defense for Education Networks, 2005, pp. 1-10, [online], Retrieved on Mar. 17, 2008, retrieved from the URL: <http://www.cisco.com/web/strategy/docs/higher—CampusSecure—defense—WP.pdf>.
Dennis McCallam et al., Real Time Intrusion Detection-Applying Correlation and Fusion for Outside the Network Attack Forecasting and Insider Attack Detection, RTO-MP-101, AC/323(IST-033)TP/18, NATO Research and Technology Organization (RTO) Information Systems Technology Panel (IST) Symposium on Real Time Intrusion Detection, May 27-28, 2002, pp. 6-1-6-13.
Dennis McCallam et al., Real Time Intrusion Detection—Applying Correlation and Fusion for Outside the Network Attack Forecasting and Insider Attack Detection, RTO-MP-101, AC/323(IST-033)TP/18, NATO Research and Technology Organization (RTO) Information Systems Technology Panel (IST) Symposium on Real Time Intrusion Detection, May 27-28, 2002, pp. 6-1-6-13.
Dorot, V. et al. "Explanatory Dictionary of Modern Computer Lexis," 2004, 3rd Ed., BHV-Petersburg, publishers, St. Petersburg, Russia, pp. 130, 239, 394, 444 (with partial English translation).
English translation of the Japanese Office Action for Appl. No. 2009-534869 dated Jun. 5, 2012 (8 pages).
European Patent Office, Extended European Search Report for Appl. No. 07868579.9 dated Jun. 4, 2014 (7 pages).
Frederic Massicotte et al., Context-Based Intrusion Detection Using Snort, Nessus and Bugtraq Databases, 3rd Annual Conference on Privacy, Security and Trust , Oct. 12-14, 2005.
Gertner Dmitrij Aleksandrovich, English Abstract of Russian Publication No. RU2002116399 entitled Personal Cryptoprotection System published Feb. 10, 2004 (2 pages).
Hans-Peter Kriegel et al., Managing Intervals Efficiently in Object-Relational Databases, Proceedings of the 26th International Conference on Very Large Databases, Cairo, Egypt, 2000, pp. 407-418.
How to Monitor the DHCP Log file, Oct. 27, 2006, pp. 1-2, [online], Retrieved on Mar. 17, 2008, retrieved from the URL: <http://support.microsoft.com/kb/298367>.
Intellectual Property Office of Singapore Written Opinion and Search Report, Singapore Patent Application No. 200901117-2, Dec. 21, 2010, fifteen pages.
Jason A. Minto, Open Source Security Information Management (OSSIM) User Guide: Monitors, Oct. 30, 2007, [online], retrieved from the internet on Apr. 4, 2008, retrieved from the URL: <http://www.ossim.net/dokuwiki/doku.php?id=user-manual:monitors>.
Jason A. Minto, Open Source Security Information Management (OSSIM) User Guide: Monitors, Oct. 30, 2007, [online], retrieved from the internet on Apr. 4, 2008, retrieved from the URL: <http://www.ossim.net/dokuwiki/doku.php?id=user—manual:monitors>.
Know Automatically who is responsible and who is affected-with stealthwatch Identity-1000, 2008, [online], Retrieved on Mar. 17, 2008, pp. 1-2, retrieved from the URL: <www.lancope.com/products/stealthwatch-id/index.aspx>.
Know Automatically who is responsible and who is affected—with stealthwatch Identity—1000, 2008, [online], Retrieved on Mar. 17, 2008, pp. 1-2, retrieved from the URL: <www.lancope.com/products/stealthwatch-id/index.aspx>.
Kuznetsov, S.A., "Large Explanatory Dictionary of Russian Language," 2000, p. 1453, Norint publishers, St. Petersburg, Russia (with partial English translation).
Microsoft Press, "Explanatory Dictionary for Computer Techniques," 1996, p. 318, Russian Edition (with partial English translation).
Moving from concepts to real solutions: Vulnerability Analysis and Best Practices for Adopting IP Communications, [online], Retrieved on Mar. 17, 2008, 2006, pp. 1, 5 & 6 of 21, retrieved from the URL: <http://www.cio.co.uk/whitepapers/index.cfm?whitepaperid=4324>.
Network Intelligence Releases Next-Generation Standard for Compliance and Security with envision v3, Oct. 11, 2005, pp. 1-3, [online], Retrieved on Mar. 17, 2008, retrieved from the URL: <http://www.rsa.com/press-release.aspx?id=7584>.
Network Intelligence Releases Next-Generation Standard for Compliance and Security with envision v3, Oct. 11, 2005, pp. 1-3, [online], Retrieved on Mar. 17, 2008, retrieved from the URL: <http://www.rsa.com/press—release.aspx?id=7584>.
New Zealand Intellectual Property Office Examination Report, New Zealand Patent Application No. 574567, Oct. 27, 2010, one page.
New Zealand Intellectual Property Office, Examination Report for Appl. No. 574567 dated Jan. 12, 2012 (3 pages).
Office Action received in Canadian Application No. 2,660,847, dated Dec. 4, 2012 (4 pages).
Optimizing Security and Network Operations-Stealthwatch Identity-1000, 2006, [online], Retrieved on Mar. 17, 2008, pp. 1-2, retrieved from the URL: <http://www.spectrum-systems.com/vendors/lancope/StealthWatch-ID-1000.pdf>.
Optimizing Security and Network Operations—Stealthwatch Identity—1000, 2006, [online], Retrieved on Mar. 17, 2008, pp. 1-2, retrieved from the URL: <http://www.spectrum-systems.com/vendors/lancope/StealthWatch—ID-1000.pdf>.
PCT International Search Report and Written Opinion, PCT/US 07/82560, Jun. 12, 2008, 8 pages.
Peter G. Neumann, The Challenges of Insider Misuse, Aug. 23, 1999, Workshop on Preventing, Detecting and Responding to Malicious Insider Misuse, Aug. 16-18, 1999, pp. 1-18, Santa Monica, CA, USA.
Polovinkin, A. et al., "Technical Art: Theory, Methodology, Practice," Inform System, 1995, p. 201, Moscow, Russia (with partial English translation).
Russian Federation Patent Office Official Action, Russian Patent Application No. 2009107162, Aug. 3, 2010, ten pages.
Russian Federation Patent Office Official Action, Russian Patent Application No. 2009107162, Feb. 2, 2010, ten pages.
Secure Associates introduces the new multi-tier architecture that creates a whole centralized monitoring environment, Jan. 8, 2006, pp. 1-3, [online] Retrieved on Mar. 17, 2008, retrieved from the URL: <http://web.archive.org/web/20070811014104/http://securesa.com/co-news-010806.htm>.
Secure Associates introduces the new multi-tier architecture that creates a whole centralized monitoring environment, Jan. 8, 2006, pp. 1-3, [online] Retrieved on Mar. 17, 2008, retrieved from the URL: <http://web.archive.org/web/20070811014104/http://securesa.com/co—news—010806.htm>.
Securify 5.3 Solution Overview, 2007, pp. 1-4, [online], Retrieved on Mar. 17, 2008, retrieved from the URL: <http://www.securify.com/pdfs/Securify-53-datasheet.pdf>.
Securify 5.3 Solution Overview, 2007, pp. 1-4, [online], Retrieved on Mar. 17, 2008, retrieved from the URL: <http://www.securify.com/pdfs/Securify—53—datasheet.pdf>.
Security Threat Mitigation (STM): The Protego Networks Mitigation and Response System (MARS), 2003, [online], Retrieved on Mar. 17, 2008, pp. 1-7, retrieved from the URL: <http://www.ihavebeenhacked.com/whitepapers/cisco-MARS.pdf>.
Security Threat Mitigation (STM): The Protego Networks Mitigation and Response System (MARS), 2003, [online], Retrieved on Mar. 17, 2008, pp. 1-7, retrieved from the URL: <http://www.ihavebeenhacked.com/whitepapers/cisco—MARS.pdf>.
Singapore Search Report dated Dec. 21, 2010 for serial No. 2009011172 filed Oct. 25, 2007 (15 pages).
Sultan Izraehl Daniehl, English Abstract of Russian Publication No. RU2241252 published Nov. 27, 2004 (2 pages).
T.K. Apostolopoulos et al., Enforcing security policies in large scale communication networks, Proceedings: 17th IEEE Symposium on Reliable Distributed Systems, Oct. 20-23, 1998, pp. 393-397. [Abstract only].
T.K. Apostolopoulos et al., SNMP-based network security management using a temporal database approach, Information Systems Security: facing the information society of the 21st century, 1996, pp. 417-427, London, UK. [Citation only].
T.K. Apostolopoulos et al., SNMP—based network security management using a temporal database approach, Information Systems Security: facing the information society of the 21st century, 1996, pp. 417-427, London, UK. [Citation only].
T.K. Apostolopoulos et al., Temporal Network Management Model Concepts and Implementation Issues, Computer Communications, Aug. 25, 1997, pp. 694-708, vol. 20, Issue No. 8. [Abstract only].
T.K. Apostolopoulos et al., The role of the time parameter in a network security management model, Proceedings: Second IEEE Symposium on Computers and Communications, Jul. 1-3, 1997, pp. 528-532. [Abstract only].
Tetsuji Takada et al., Tudumi: Log Information Visualization System for Intrusion Detection, UEC-IS-TR-2000-08, Sep. 2000, pp. 1-10.
TW Office Action Mailed Jun. 24 2013 for Serial No. 96140097 filed Oct. 25, 2007.
U.S. Appl. No. 10/308,415, filed Dec. 2, 2002, [copy not enclosed].
U.S. Appl. No. 10/308,417, filed Dec. 2, 2002, [copy not enclosed].
U.S. Appl. No. 10/976,075, filed Oct. 27, 2004, [copy not enclosed].
U.S. Appl. No. 11/023,942, filed Dec. 24, 2004, pp. 1-26.
U.S. Appl. No. 11/923,513, filed Dec. 24, 2007, [copy not enclosed].
U.S. Appl. No. 11/966,078, filed Dec. 28, 2007, [copy not enclosed].
Watanabe, Hidetoshi; Part 1, Log management for figuring out user behavior: the purpose of log management is to monitor work processes. [yüzä no kyodö wo haaku suru tame no rogu kanri: rogu kanri no mokuteki wa gyömu purosesu no kanshi], Network World, Japan; IDG Japan, Inc.; Oct. 1, 2006 vol. 11 No. 10, pp. 48-53.
Watanabe, Hidetoshi; Part 2, How does one collect and save log information for tracking and evidence purposes? Six log management points for maintaining compliance [shöseki shöko to shite rogu jöhö wo sh0sh0 hozon suru ni wa? Konpuraiansu no tame no rogu kanri muttsu no pointo], Network World, Japan; IDG Japan, Inc.; Oct. 1, 2006 vol. 11 No. 10, pp. 54-57.

matches:
Application No. 60
V.
Application No. 200901117
Application No. 574567
Application No. 2
Application No. 2009107162
Application No. 2009107162


D.C. Law Library - D.C. Law 21-257. Urban Farming and Food Security Amendment Act of 2016.
D.C. Law 21-257. Urban Farming and Food Security Amendment Act of 2016.
↪ D.C. Law 21-257. Urban Farming and Food Security Amendment Act of 2016.
Law 21-257, the “Urban Farming and Food Security Amendment Act of 2016,” was introduced in the Council and assigned Bill No. 21-293 which was referred to the Committee of the Whole. The bill was adopted on first and second readings on July 12, 2016, and Dec. 20, 2016, respectively. After mayoral review, it was assigned Act No. 21-674 on Feb. 15, 2017, and transmitted to Congress for its review. D.C. Law 21-257 became effective Apr. 7, 2017.
To amend the Food Production and Urban Gardens Program Act of 1986 to update existing law pertaining to urban farming, to create an urban farming leasing initiative for District-owned land, to specify criteria for applicants to participate in the initiative, to exempt property leased pursuant to the initiative from real property and possessory interest taxation, and to create a reporting requirement; to amend Title 47 of the District of Columbia Official Code to abate 90% of the tax on private land used as an urban farm and to repeal tax credits for donations of certain food commodities grown in the District.
BE IT ENACTED BY THE COUNCIL OF THE DISTRICT OF COLUMBIA, That this act may be cited as the "Urban Farming and Food Security Amendment Act of 2016".
"(1) "Department" means the Department of General Services.
"(2) "Horticultural techniques" means the scientific, artistic, and technological methods used to cultivate and manage an agricultural space, such as growing from the ground, hydroponics, container farming, vertical farming, or growing in greenhouses or raised beds.
"(3) "Produce" means any substance produced for human consumption and nourishment using horticultural techniques, such as vegetables, fruits, grains, mushrooms, honey, herbs, nuts, seeds, and rootstock.
"(4) "Urban farm" means any property in the District of Columbia that is used for the growing, cultivating, processing, and distributing of produce for profit, not for profit, or for educational purposes.
"(B) Is not the subject of a pending agreement for development or sale.".
(b) Section 3 (D.C. Official Code § 48-402) is repealed.
"Sec. 3a. Urban Farming Land Lease Program.
"(a) There is established within the Department the Urban Farming Land Lease Program ("Program"), which shall enable a qualified applicant identified pursuant to subsection (c) of this section to enter into a lease agreement with the Department to create and maintain an urban farm on vacant land identified pursuant to subsection (b) of this section.
"(b) The Department shall, in consultation with the Office of Planning and no less frequently than annually, identify vacant land in the inventory of real property assets maintained pursuant to section 1026 of the Department of General Services Establishment Act of 2011, effective September 14, 2011 (D.C. Law 19-21; D.C. Official Code § 10-551.05), that is suitable for use as an urban farm.
"(4) Meet any additional criteria the Department establishes pursuant to the rules issued pursuant to subsection (g) of this section.
"(3) Permit the sale of produce on or off the leased property after the lessee provides the Department with proof that the soil has been tested for, and found to be substantially free of, contamination from arsenic, lead, and heavy metals.
"(e) Property leased pursuant to this section shall be exempt from real property taxation and possessory interest taxation.
"(3) Information on how applicants may apply to the Program.
"(g) The Mayor, pursuant to Title I of the District of Columbia Administrative Procedure Act, approved October 21, 1968 (82 Stat. 1204; D.C. Official Code § 2-501 et seq.), may issue rules to implement the provisions of this section.".
"Sec. 3b. Limitations on expenditures.
"No more than $400,000 in Fiscal Year 2016 and $350,000 in each fiscal year thereafter shall be used by the Mayor to implement the Urban Farming Land Lease Program established pursuant to section 3a and to administer the real property tax abatement for certain urban farms established pursuant to D.C. Official Code § 47-868, and the tax-exempt status conferred by D.C. Official Code § 47-1005(c).".
"Sec. 3c. Non-liability of the District.
"Nothing in this act shall be construed to create governmental liability or a cause of action against the District related to the safety of food produced on land leased from the District pursuant to section 3a.".
(1) The table of contents is amended by striking the section designation "47-868. Reduced tax liability for agricultural uses." and inserting the section designation "47-868. Reduced tax liability for certain urban farms." in its place.
"Sec. 47-868. Reduced tax liability for certain urban farms.
"(a) Except as provided in subsection (b) of this section, if real property is used as an urban farm, then 90% of the real property tax otherwise levied pursuant to § 47-811 on the portion of the real property exclusively in use as an urban farm shall be abated for each real property tax year that such portion of the real property is used as an urban farm; provided, that if an urban farm is located in an improvement to real property, the abatement shall be applied only to the real property tax otherwise levied pursuant to § 47-811 on the portion of the improvement in use as an urban farm.
"(b)(1) An abatement permitted under this section shall not exceed the tax liability for the entire parcel of real property on which the urban farm is located, taking into account any other applicable abatements, exemptions, or reductions.
"(2) If real property is put to use as an urban farm at some time other than at the beginning of the tax year, the 90% tax abatement provided for in subsection (a) of this section shall be pro-rated according to the portion of the real-property tax year that the real property is in use as an urban farm, notwithstanding any other provision of this section.
"(3) No abatement under this section shall exceed $20,000 per parcel of real property, per tax year.
"(4) No abatement shall be permitted for an abutting parcel of real property with common or related ownership that is not in use as an urban farm.
"(5) If the amount of tax to be abated for any half tax year for all properties certified under subsection (f)(1) of this section exceeds the total amount of funds available as certified under subsection (f)(2) of this section, the available funds shall be allocated pro rata among all properties certified under subsection (f)(1) of this section.
"(c) The abatement described in subsection (a) of this section may be apportioned semiannually.
"(d)(1) To be eligible to apply for an abatement under this section, an applicant shall, before the property is put to use as an urban farm, submit a proposed annual planting plan to the Department of General Services ("Department") for approval. The annual planting plan may include season-appropriate uses of an urban farm, such as providing cover crops, a bee hive, or growing seedlings in a greenhouse.
"(2) After an applicant submits a proposed annual planting plan, the Department shall have 30 calendar days during which to object to the proposed annual planting plan and request modifications to the annual planting plan. If no objection is made within 30 calendar days of submission, the annual planting plan shall be considered approved.
"(3) Once approved, the applicant shall retain the annual planting plan for at least 3 years and shall provide the annual planting plan in the event of an audit.
"(e)(1) A real property owner requesting a tax abatement under this section shall apply for and provide documentation supporting the tax abatement claim in the form and manner prescribed by the Department pursuant to rules established under subsection (h) of this section.
"(2) A real property owner receiving a tax abatement under this section shall make such reports concerning the use of property as may be prescribed by the Department pursuant to rules established under subsection (h) of this section.
"(3) A property owner denied an abatement under this section shall have the appeal rights provided by § 47-1009.
"(f)(1) The Department shall certify semiannually to the Office of Tax and Revenue ("OTR"), in a form and medium prescribed by OTR, each property or portion thereof eligible to receive a real property tax abatement pursuant to this section, as well as the period of time for which the property is eligible for a tax abatement under this section.
"(2) The certification required by paragraph (1) of this subsection shall be accompanied by a statement from the Department specifying the amount of funds available under section 3b of the Food Production and Urban Gardens Program Act of 1986, effective October 22, 2015 (D.C. Law 21-36; D.C. Official Code § 48-402.02), for real property tax abatements for the properties identified pursuant to paragraph (1) of this subsection.
"(B) The real property was in use as an urban farm continuously throughout the abatement period pursuant to an approved annual planting plan.
"(g) For the purposes of this section, the terms "urban farm" and "produce" shall have the same meaning as provided in section 2 of the Food Production and Urban Gardens Program Act of 1986, effective February 28, 1987 (D.C. Law 6-210; D.C. Official Code § 48-401).
"(h) The Mayor, pursuant to Title I of the District of Columbia Administrative Procedure Act, approved October 21, 1968 (82 Stat. 1204; D.C. Official Code § 2-501 et seq.), may issue rules to implement the provisions of this section.".
(A) Strike the section designation "47-1806.14. Tax on residents and nonresidents – Credits – Tax credits for farm to food donations." and insert the section designation "47-1806.14. Tax on residents and nonresidents – Credits – Tax credits for farm to food donations. [Repealed]." in its place.
(B) Strike the section designation "47-1807.12. Tax on corporations and financial institutions – Credits – Tax credit for farm to food donations." and insert the section designation "47-1807.12. Tax on corporations and financial institutions – Credits – Tax credit for farm to food donations. [Repealed]." in its place.
(C) Strike the section designation "47-1808.12. Tax on unincorporated businesses – Credits – Tax credit for farm to food donations." and insert the section designation "47-1808.12. Tax on unincorporated businesses – Credits – Tax credit for farm to food donations. [Repealed]." in its place.
(2) Section 47-1806.14 is repealed.
(3) Section 47-1807.12 is repealed.
(4) Section 47-1808.12 is repealed.


UNITED STATES of America, Plaintiff–Appellee v. Christopher HUM, Defendant–Appellant.
Before BYE, COLLOTON, and KELLY, Circuit Judges. Anne E. Gardner, Assistant United States Attorney, argued, Little Rock, AR, for Plaintiff–Appellee. William Owen James, Jr., argued, Little Rock, AR, for Defendant–Appellant.
On August 15, 2006, Hum pled guilty to conspiracy to manufacture 500 grams or more of methamphetamine under 21 U.S.C. § 846. On December 8, 2006, Hum was sentenced to four years of imprisonment followed by five years of supervised release. On January 8, 2010, Hum began his term of supervised release. On September 7, 2012, Hum's probation officer filed a petition requesting the court set a revocation hearing based on Hum's failure to report for drug testing on five occasions; his submission of urine samples that tested positive for controlled substances on four occasions; his attempt to alter his drug test through the use of a “whizzonator” on December 1, 2010; and his arrest for assault on August 24, 2012. On January 28, 2013, a status hearing on the petition was set for February 4, 2013. On January 30, 2013, Hum submitted a urine sample that was later confirmed positive for marijuana. When Hum appeared for the February 4 status hearing, he again submitted a urine sample that tested positive for marijuana. At the conclusion of the status hearing, and by agreement of the parties, the district court modified Hum's supervised release conditions to include placement in a residential re-entry center for six months.
If you take this four months, go on down and do your four months and come on back out, or essentially what you can do is you can hold five years over your head. Because if you come back in my courtroom, I'm giving you the max. You understand?
From what I see, most people who have drug problems don't choose to. Who would choose to be addicted to drugs or alcohol or anything. It's something that's not of your choosing, but it's something that has you in its grips. And most people who are on drugs, when everything's going fine, they're doing fine. But what happens when you're depressed and it's two o'clock in the morning or three o'clock in the morning and the drugs start calling you.
That's where your problem's going to come in. And what I would say to you is, if that happens to you, you just start weighing out, is it worth five years. And for everybody back there who's supporting you right now in court, I want y'all to know if he slips up, I'm sending him away for five years. And I'm just telling you right now that's what's going to happen, so we've made the deal, I'm willing to live by it, Mr. Hum. I just hope you are. Okay?
Hum again confirmed that he understood the consequences of not abiding by the terms of his supervised release. The court then revoked Hum's term of supervised release, and ordered that he remain at the center until September 11, 2013, approximately three more months.
After the May 31, 2013, revocation hearing, Hum again violated the terms of his supervised release: on July 4, 2013, Hum returned to the residential re-entry center after consuming alcohol, registering over .02 on a breathalyzer test; and he was terminated from the center on July 8, 2013, for non-compliance with the program. In addition, on August 19, 2013, Hum provided a urine sample that tested positive for amphetamine, and he admitted to his probation officer that he had used Adderall, a drug for which he did not have a lawful prescription. The district court held a hearing on these additional violations on August 30, 2013. At this hearing, the court reviewed with Hum in detail the discussion they had at the May 2013 hearing about the consequences of any additional violations of his supervised release. Hum acknowledged the district court had advised him at the May hearing that he faced a sentence of imprisonment of 60 months if he again violated the terms of his release. Hum admitted the new violations, which the court found were “Grade C” violations. With a criminal history category II, the advisory sentencing guideline range was 4–10 months' imprisonment. Hum asked for a sentence within the advisory guideline range; the government made no recommendation.
We review the substantive reasonableness of a revocation sentence under a deferential abuse-of-discretion standard. United States v. Merrival, 521 F.3d 889, 890 (8th Cir.2008). “A district court abuses its discretion and imposes an unreasonable sentence when it fails to consider a relevant and significant factor, gives significant weight to an irrelevant or improper factor, or considers the appropriate factors but commits a clear error of judgment in weighing those factors.” United States v. Kreitinger, 576 F.3d 500, 503 (8th Cir.2009) (quotation omitted). “Although the district court is required to consider certain factors set forth in [18 U.S.C.] § 3553(a) in a supervised-release-revocation sentencing, there is no requirement that the district court make specific findings relating to each of the factors considered.” United States v. Franklin, 397 F.3d 604, 606–07 (8th Cir.2005) (internal quotation and footnote omitted). A district court does not need to “mechanically list” every § 3553(a) factor considered; “[a]ll that is required is evidence that the court has considered the relevant matters and that some reason be stated for its decision.” United States v. White Face, 383 F.3d 733, 740 (8th Cir.2004) (citation omitted). “If a sentencing judge references some of the considerations contained in § 3553(a), we are ordinarily satisfied that the district court was aware of the entire contents of the relevant statute.” Id. (quotation omitted).
Hum asserts the district court failed to consider relevant factors, instead relying exclusively on an improper factor—the court's “promise/threat” to sentence him to the maximum sentence should he again violate the terms of his supervised release. Hum argues the sentence was too harsh given that his violations were Grade C violations. He further contends the court did not take into consideration the factors set forth in 18 U.S.C. § 3553(a), specifically the “goals of deterrence, incapacitation, rehabilitation, and sentencing uniformity.” We disagree.
Contrary to Hum's assertions, the district court properly considered relevant sentencing factors before imposing the sentence. The court noted the leniency Hum previously had been shown when his supervised release was modified, rather than revoked. The court also recognized the need for both specific and general deterrence. The court read almost verbatim from the transcript of the May 2013 hearing, reminding Hum of what he had agreed to in exchange for the opportunity to return to the residential re-entry center in lieu of prison, and it expressed the importance of maintaining respect for the court's directives generally. Finally, the court noted that Hum had been difficult to supervise, and that he had portrayed an attitude “almost like the rules [didn't] apply to [him].” Based on the reasons given by the court, which were well explained to Hum, we cannot say the sentence, while lengthy, was unreasonable. See, e.g., United States v. Larison, 432 F.3d 921, 924 (8th Cir.2006) (concluding 60–month revocation sentence not unreasonable even though advisory guideline range was 5–11 months when court considered defendant's repeated violations of supervised release, inability to complete drug treatment programs, and continuing criminal conduct despite probation office leniency). Therefore, we affirm.
1. The Honorable Brian Miller, Chief Judge, United States District Court for the Eastern District of Arkansas.


One who lends a sum of money to a partnership under an agreement that he shall be paid interest thereon at all events, and shall also be paid one tenth of the yearly profits of the partnership business if those profits exceed the sum lent, does not thereby become liable as a partner for the debts of the partnership.
executor of William G. Perry, both citizens of Pennsylvania, alleging Perry to have been a partner with Lawrence W. Counselman and Albert L. Scott, under the name of L. W. Counselman & Co., and counting on promissory notes of various dates from August 10, 1883, to November 25, 1884, signed by that firm, endorsed to the plaintiff, and amounting in all to about $10,000, with interest. The defendant denied that Perry was a partner in the firm.
" L. W. Counselman Albert L Scott "
"Office of L. W. Counselman & Co., Oyster and Fruit Packers"
"corner Philpot and Will Streets"
"Baltimore, Md. March 15, 1880"
"For and in consideration of loans made and to be made to us by Wm. G. Perry, of Philadelphia, amounting in all to the sum of ten thousand dollars, for the term of one year from the date of said loans, we agree to pay to said Wm. G. Perry, in addition to the interest thereon, one tenth of the net profits over and above the sum of ten thousand dollars on our business for the year commencing May 1st, 1880, and ending May 1st, 1881 -- i.e., if our net profits for said year's business exceed the sum of ten thousand dollars, then we are to pay to said W. G. Perry one tenth of said excess of profits over and above the said sum of ten thousand dollars, and it is further agreed that if our net profits do not exceed the sum of ten thousand dollars, then he is not to be paid more than the interest on said loan, the same being added to notes at the time they are given, which are to date from the time of said loans, and payable one year from date."
"L. W. COUNSELMAN & Co."
"March 2, 1881. This contract and agreement is to continue one year longer on the same basis -- i.e., from May 1st, 1881, until May 1st, 1882."
"We hereby renew the agreement made with you May 1, 1880, which is to the effect that we will guarantee you ten percent interest upon loans amounting to $10,000, and that if the net profits of our business are over $10,000 for the year commencing May 1, 1882, and ending April 30th, 1883, we will in lieu of the ten percent interest give you ten percent of the profits. We have two propositions for partnership May 1st, and if we accept either, we will then, if you desire, return your loan."
The plaintiff further offered in evidence six promissory notes, amounting in the aggregate to $10,600, given by the firm to Perry in the months of March, May, and June, 1884.
"Question. Mr. Counselman and yourself did owe this $10,000 to the estate of Mr. Perry, did you?"
"Answer. They had my notes for it."
"Q. Did you or did you not owe it?"
"A. It was capital he had in the business the same as ours. We owed it to him. Of course, we owed it to him if we did not lose it."
At the close of the plaintiff's evidence, the defendant moved for a nonsuit on the ground that there was no evidence to show that Perry was liable as a partner. The court so ruled, and ordered a nonsuit. 29 F. 276. The plaintiff duly excepted to the ruling, and sued out this writ of error.
The granting of a nonsuit by the circuit court, because in its opinion the plaintiff had given no evidence sufficient to maintain his action, was in accordance with the law and practice of Pennsylvania prevailing in the courts of the United States held within that state, and is subject to the revision of this Court on writ of error. Central Transportation Co. v. Pullman's Car Co., 139 U. S. 24, 139 U. S. 38-40. The real question in this case, therefore, is whether the evidence introduced by the plaintiff would have been sufficient to sustain a verdict in his favor.
The requisites of a partnership are that the parties must have joined together to carry on a trade or adventure for their common benefit, each contributing property or services and having a community of interest in the profits. Ward v. Thompson, 22 How. 330, 63 U. S. 334.
Winship v. Bank, of United States, 5 Pet. 529, 30 U. S. 561-562. And the Chief Justice referred to Waugh v. Carver, 2 H.Bl. 235; Ex Parte Hamper, 17 Ves. 403, 412, and Gow on Partnership 17.
How far sharing in the profits of a partnership shall make one liable as a partner has been a subject of much judicial discussion, and the various definitions have been approximate, rather than exhaustive.
The rule formerly laid down and long acted on as established was that a man who received a certain share of the profits as profits, with a lien on the whole profits as security for his share, was liable as a partner for the debts of the partnership, even if it had been stipulated between him and his co-partners that he should not be so liable, but that merely receiving compensation for labor or services, estimated by a certain proportion of the profits, did not render one liable as a partner. Story on Partnership, c. 4; 3 Kent Com. 25, note, 32-34; Ex Parte Hamper, above cited; Pott v. Eyton, 3 C.B. 32, 40; Bostwick v. Champion, 11 Wend. 571, and 18 Wend. 175, 184-185; Burckle v. Eckart, 1 Denio 337 and 3 N.Y. 132; Denny v. Cabot, 6 Metc. 82; Fitch v. Harrington, 13 Gray 468, 474; Brundred v. Muzzy, 25 N.J.Law 268, 279, 674. The test was often stated to be whether the person sought to be charged as a partner took part of the profits as a principal, or only as an agent. Benjamin v. Porteus, 2 H.Bl. 590, 592; Collyer on Partnership (1st ed.) 14; Smith, Merc.Law, (1st ed.) 4; Story on Partnership § 55; Loomis v. Marshall, 12 Conn. 69, 78; Burckle v. Eckart, 1 Denio 337, 341; Hallet v. Desban, 14 La.Ann. 529.
"may have expressly stipulated with his associates against all the usual incidents to that relation. That rule, however, has no application whatever to a case of service or special agency, where the employee has no power as a partner in the firm and no interest in the profits, as property, but is simply employed as a servant or special agent, and is to receive a given sum out of the profits, or a proportion of the same, as a compensation for his services."
Berthold v. Goldsmith, 24 How. 536, 65 U. S. 542-543. See also Seymour v. Freer, 8 Wall. 202, 75 U. S. 215, 75 U. S. 222-226; Beckwith v. Talbot, 95 U. S. 289, 95 U. S. 293; Edwards v. Tracy, 62 Penn.St. 374; Burnett v. Snyder, 81 N.Y. 550, 555.
"Every partner is an agent of the partnership, and his rights, powers, duties, and obligations are in many respects governed by the same rules and principles as those of an agent. A partner indeed virtually embraces the character both of a principal and of an agent. So far as he acts for himself and his own interest in the common concerns of the partnership, he may properly be deemed a principal, and so far as he acts for his partners, he may as properly be deemed an agent. The principal distinction between him and a mere agent is that he has a community of interest with the other partners in the whole property and business and responsibilities of the partnership, whereas an agent, as such, has no interest in either. Pothier considers partnership as but a species of mandate, saying contractus societatis, non secus ac contractus mandati. Afterwards, in discussing the reasons and limits of the rule by which one may be charged as a partner by reason of having received part of the profits of the partnership, Mr. Justice Story observed that the rule was justified, and the cases in which it had been applied reconciled, by considering that"
"a participation in the profits will ordinarily establish the existence of a partnership between the parties in favor of third persons, in the absence of all other opposing circumstances,"
of itself overcoming or controlling them,"
"The true rule, ex aequo et bono, would seem to be that the agreement and intention of the parties themselves should govern all the cases. If they intended a partnership in the capital stock, or in the profits, or in both, then that the same rule should apply in favor of third persons, even if the agreement were unknown to them. And on the other hand, if no such partnership were intended between the parties, then that there should be none as to third persons unless where the parties had held themselves out as partners to the public, or their conduct operated as a fraud or deceit upon third persons."
Story on Partnership §§ 1 38, 49.
Baron Parks (afterwards Lord Wensleydale) appears to have taken much the same view of the subject as Mr. Justice Story. Both in the Court of Exchequer and in the House of Lords he was wont to treat the liability of one sought to be charged as a dormant partner for the acts of the active partners as depending on the law of principal and agent. Beckham v. Drake (1841), 9 M. & W. 79, 98; Wilson v. Whitehead (1842), 10 M. & W. 503, 504; Ernest v. Nicholls (1857), 6 H.L.Cas. 401, 417; Cox v. Hickman (1860), 8 H.L.Cas. 268, 312. And in Cox v. Hickman, he quoted the statements of Story and Pothier from Story on Partnership § 1, above cited.
under the assignment. The decision was put upon the ground that the liability of one partner for the acts of his co-partner is in truth the liability of a principal for the acts of his agent; that a right to participate in the profits, though cogent, is not conclusive, evidence that the business is carried on in part for the person receiving them, and that the test of his liability as a partner is whether he has authorized the managers of the business to carry it on in his behalf. Cox v. Hickman, 8 H.L.Cas. 268, 304, 306, 312-313, s.c. nom. Wheatcroft v. Hickman, 9 C.B. (N.S.) 47, 90, 92, 98-99.
This new form of stating the general rule did not at first prove easier of application than the old one, for in the first case which arose afterwards, one judge of three dissented, Kilshaw v. Jukes, 3 B. & S. 847, and in the next case, the unanimous judgment of four judges in the Common Bench was reversed by four judges against two in the Exchequer Chamber, Bullen v. Sharp, 18 C.B. (N.S.) 614, and L.R. 1 C.P. 86. And, as has been pointed out in later English cases, the reference to agency as a test of partnership was unfortunate and inconclusive, inasmuch as agency results from partnership, rather than partnership from agency. Kelly, C.B., and Cleasby, B., in Holme v. Hammond, L.R. 7 Exch. 218, 227, 233; Jessel, M.R., in Pooley v. Driver, 5 Ch.D. 458, 476. Such a test seems to give a synonym, rather than a definition -- another name for the conclusion, rather than a statement of the premises from which the conclusion is to be drawn. To say that a person is liable as a partner who stands in the relation of principal to those by whom the business is actually carried on adds nothing by way of precision, for the very idea of partnership includes the relation of principal and agent.
"You cannot grasp the notion of agency, properly speaking, unless you grasp the notion of the existence of the firm as a separate entity from the existence of the partners -- a notion which was well grasped by the old Roman lawyers, and which was partly understood in the courts of equity."
has more steadfastly adhered to the old form of stating the rule, has held that a partnership, though not strictly a legal entity as distinct from the persons composing it, yet being commonly so regarded by men of business, might be so treated in interpreting a commercial contract. Bank of Buffalo v. Thompson, 121 N.Y. 280.
In other respects, however, the rule laid down in Cox v. Hickman has been unhesitatingly accepted in England, as explaining and modifying the earlier rule. In re English & Irish Society, 1 Hem. & Mil. 85, 106-107; Mollow v. Court of Wards, L.R. 4 P.C. 419, 435; Ross v. Parkyns, L.R. 20 Eq. 331, 335; Ex Parte Tennant, 6 Ch.D. 303; Ex Parte Delhasse, 7 Ch.D. 511; Badeley v. Consolidated Bank, 38 Ch.D. 238. See also Davis v. Patrick, 122 U. S. 138, 122 U. S. 151; Eastman v. Clark, 53 N.H. 276; Wild v. Davenport, 48 N.J.Law 129; Seabury v. Bolles, 51 N.J.Law 103 and 52 N.J.Law 413; Morgan v. Farrel, 58 Conn. 413.
In the present state of the law upon this subject, it may perhaps be doubted whether any more precise general rule can be laid down than, as indicated at the beginning of this opinion, that those persons are partners who contribute either property or services to carry on a joint business for their common benefit, and who own and share the profits thereof in certain proportions. If they do this, the incidents or consequences follow that the acts of one in conducting the partnership business are the acts of all, that each is agent for the firm and for the other partners, that each receives part of the profits as profits, and takes part of the fund to which the creditors of the partnership have a right to look for the payment of their debts, that all are liable as partners upon contracts made by any of them with third persons within the scope of the partnership business, and that even an express stipulation between them that one shall not be so liable, though good between themselves, is ineffectual as against third persons. And participating in profits is presumptive, but not conclusive, evidence of partnership.
that an agent or servant whose compensation is measured by a certain proportion of the profits of the partnership business is not thereby made a partner in any sense. So an agreement that the lessor of a hotel shall receive a certain portion of the profits thereof by way of rent does not make him a partner with the lessee. Perine v. Hankinson, 11 N.J.Law 181; Holmes v. Old Colony Railroad, 5 Gray 58; Beecher v. Bush, 45 Mich. 188. And it is now equally well settled that the receiving of part of the profits of a commercial partnership in lieu of or in addition to interest by way of compensation for a loan of money, has of itself no greater effect. Wilson v. Edmonds, 130 U. S. 472, 130 U. S. 482; Richardson v. Hughitt, 76 N.Y. 55; Curry v. Fowler, 87 N.Y. 33; Cassidy v. Hall, 97 N.Y. 159; Smith v. Knight, 71 Ill. 148; Williams v. Soutter, 7 Ia. 435, 446; Boston & Colorado Smelting Co. v. Smith, 13 R.I. 27; Mollow v. Court of Wards, and Badeley v. Consolidated Bank, above cited.
"If cases should occur where any persons, under the guise of such an arrangement, are really trading as principals, and putting forward, as ostensible traders, others who are really their agents, they must not hope by such devices to escape liability, for the law in cases of this kind will look at the body and substance of the arrangements and fasten responsibility on the parties according to their true and real character."
L.R. 4 P.C. 438. But in the case at bar, no such element is found.
which they gave him their promissory notes, is spoken of as a loan, for which the partnership was to pay him legal interest at all events, and also pay him one tenth of the net yearly profits of the partnership business if those profits should exceed the sum of $10,000. The manifest intention of the parties, as apparent upon the face of the agreements, was to create the relation of debtor and creditor, and not that of partners. Perry's demanding and receiving accounts and payments yearly was in accordance with his right as a creditor. There is nothing in the agreement itself, or in the conduct of the parties, to show that he assumed any other relation. He never exercised any control over the business. The legal effect of the instrument could not be controlled by the testimony of one of the partners to his opinion that "it was capital he had in the business the same as ours; we owed it to him; of course, we owed it to him if we did not lose it."
Upon the whole evidence, a jury would not be justified in inferring, on the part of Perry, either "actual participation in the profits as principal," within the rule as laid down by this Court in Berthold v. Goldsmith, or that he authorized the business to be carried on in part for him or on his behalf, within the rule as stated in Cox v. Hickman and the later English cases. There being no partnership in any sense, and Perry never having held himself out as a partner to the plaintiff or to those under whom he claimed, the circuit court rightly ruled that the action could not be maintained. Pleasants v. Fant, 22 Wall. 116; Thompson v. Toledo Bank, 111 U. S. 529.


Debt Collector Sue you in the Wrong County? Your Statute of Limitations to Retaliate.
Consumers generally have one year in which to sue a debt collector for violating the Fair Debt Collection Practices Act (FDCPA). Courts are generally strict in enforcing the one-year time limitation known as the "statute of limitations." But alive and kicking to possibly extend that deadline is the doctrine of "equitable tolling" and possibly even the "discovery rule."
Equitable tolling may extend the deadline to when the violation is discovered if the debt collector conceals facts or makes a misrepresentation that would conceal or hinder a consumer's ability to discover the wrong. To benefit from this privilege, the consumer must exercise a minimal degree of diligence in discovering and enforcing her rights.
For example, we saw in Coble v. Cohen & Slamowitz a group of class-action plaintiffs successfully argue an equitable tolling of the statute of limitations during the time period when the law firm was enforcing judgments it had reason to believe were premised on fraudulent affidavits of service.
Along the same lines, we saw the court in Sykes v. Mel Harris also apply the doctrine of equitable tolling to FDCPA claims relating to allegations of "sewer service," a process of falsifying affidavits of service.
But what about the situation where the debt collector files the case in the wrong county (itself a violation of FDCPA § 1692i known as a "venue violation") without such an affirmative act of concealment or implication of fraud? Is the consumer permitted to extend the one-year limitation from when she merely discovered the venue violation?
In other words is there a less-burdensome "discovery rule" in FDCPA actions that would trigger the one-year deadline from when a consumer discovered—or should have discovered using due diligence—the venue violation? Courts seem to be unsettled on this issue. But relying on a 5th Circuit case, Sema v. Law Office of Joseph Onwuteaka, P.C., a federal court in the 2nd Circuit (where we practice law), Sam v. Cohen & Slamowitz, LLP, seems to rule that the more relaxed discovery rule should apply in cases where consumers learn they were sued in the wrong county. This rule makes sense. It just wouldn't seem fair to make the unwitting consumer absorb the loss of an improper case filing in a distant forum. The Sema court opined that the broader phraseology of "bringing an action" versus "filing an action" is broad enough to conclude that Congress did not intend to confine the violative act to the date of filing the complaint alone. This interpretation seems to comport with the rationale of preventing consumers from having to appear in distant courts at any stage.
 Sema v. Law Office of Joseph Onwuteaka, P.C., 732 F.3d 440 (5th Cir. 2013).
 Sam v. Cohen & Slamowitz, LLP, 2015 WL 114076 at *1 (WDNY, Jan. 8, 2015).