Mapping Use Cases to Logs. Which Logs are the Most Important to Collect?
When it comes to log collection, it is always difficult to figure out what to to capture. The primary reasons are cost and value. Of course you can capture every logs flowing in your network but if you don't have a use case to attach to its value, that equals to wasted storage and money. Really not ideal since most Security Information Management (SIM) also referred to Security Information and Event Management (SIEM) have a daily cost associate with log capture. Before purchasing a SIM, the first task that is often difficult is, what do I collect and why? We want quality over quantity. Again, what you collect has a cost, the minimum amount of time logs are retained (how many years) must be calculated because it directly related to the number of events per second (EPS) collected daily [1], how many log collector are necessary to capture what you need, etc.
Next, it is important to identify your top five use cases, based on value that can have an immediate impact with the security team. This part is often difficult to pin point because it usually isn't an exercise the stakeholders have already worked out, in the end, it must map to the use case, what do I need to capture to be successfully alerted on? When the use cases have been identified, it is time to figure out what logs are necessary to identify the threat as it happen. You may have already identified some threats based on previous incidents which can be translated into a use case.
If you are looking for some examples, Anton Chuvakin [2][3] has written extensively on SIEM and is a good place to start. The next thing to do after you have identified your five use case, determine the quality of your logs into a spreadsheet into five category; identify the log source (firewall, IPS, VPN, etc.), its category (user activity, email, proxy, etc.) , its priority (high, medium, low), information type (IP, hostname, username, etc.) and matching use case (authentication, suspicious outbound activity, web application attack, etc.)[4]. The last step is to identify the SIM that will meet your goals.
[1] http://www.buzzcircuit.com/tag/siem-storage-calculator/
[2] http://blogs.gartner.com/anton-chuvakin/2014/05/14/popular-siem-starter-use-cases/
[3] http://blogs.gartner.com/anton-chuvakin/2013/09/24/detailed-siem-use-case-example/
[4] http://journeyintoir.blogspot.ca/2014/09/siem-use-case-implementation-mind-map.html
[5] https://isc.sans.edu/forums/diary/SIEM+is+not+a+product+its+a+process/20399
-----------
Guy Bruneau IPSS Inc.
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu
Comments
Use it as you will, but its fairly comprehensive.
How one appropriately captures each audit record may vary greatly between systems and organizations.
AU-2 Implementation Standards
1. Generate audit records for the following auditable events:
a. Server alerts and error messages;
b. Log onto system;
c. Log off system;
d. Change of password;
e. All system administrator commands, while logged on as system administrator;
f. Switching accounts or running privileged actions from another account, (e.g. Linux/UNIX SU or Windows RUNAS);
g. Creation or modification of super-user groups;
h. Subset of security administrator commands, while logged on in the security administrator role;
I. Subset of system administrator commands, while logged on in the user role;
j. Clearing of the audit log file;
k. Startup and shutdown of audit functions;
l. Use of identification and authentication mechanisms (e.g., user ID and password);
m. Change of file or user permissions or privileges (e.g., use of suid/guid, chown, su);
n. Remote access outside of the corporate network communication channels(e.g., modems, dedicated Virtual private Network ) and all dial-in access to the system;
o. Changes made to an applications or database by a batch file;
p. Application-critical record changes;
q. Changes to database or application records, where the application has been bypassed to produce the change (via a file or other database utility);
r. User log-on and log-off (successful or unsuccessful);
s. System shutdown and reboot;
t. System errors;
u. Application shutdown;
v. Application restart;
w. Application errors;
x. Security policy modifications; and
y. Printing sensitive information.
2. Subset of Implementation Standard 1, Enable logging for perimeter devices, including firewalls and routers:
a. User log-on and log-off (successful or unsuccessful);
b. Log packet-screening denials originating from untrusted networks;
c. All system administration activities;
d. Packet-screening denials originating from trusted networks;
e. Account creation, modification, or deletion of packet filters;
f. System shutdown and reboot;
g. System errors; and
h. Modification of proxy services.
3. Verify that proper logging is enabled to audit administrator activities.
4. 5 U.S.C §552a(c) Accounting of Certain Disclosures:
Each agency shall keep an accurate accounting of the date, nature and purpose of each disclosure of a record to any person/entity or other agency and the name and address of the person/entity or agency to whom the disclosure is made. The agency must retain the accounting for at least five years or the life of the record whichever is longer after the disclosure for which the accounting is made, make the accounting available to the individual named in the record at his request; and inform any person/entity or other agency about any correction or notation of dispute made by the agency of any record that has been disclosed to the person or agency if an accounting of the disclosure was made.
NOTE: The systems where we must apply this standard involve PHI handling, so this set of audit record types would likely work for any HIPAA relevant systems. We are applying the standard as universally as possible across all of our data systems to simplify processes, training, and knowledge management.
I hope this helps some of you struggling with this problem. :-)
Anonymous
Jun 19th 2017
7 years ago