File size: 6,805 Bytes
7c89ed7 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 | Sending logs to MozDef
----------------------
Events/Logs are accepted as json over http(s) with the POST or PUT methods or over rabbit-mq.
Most modern log shippers support json output. MozDef is tested with support for:
* `heka`_
* `beaver`_
* `nxlog`_
* `logstash`_
* `rsyslog`_
* `native python code`_
* `AWS cloudtrail`_ (via native python)
We have `some configuration snippets`_
.. _heka: https://github.com/mozilla-services/heka
.. _beaver: https://github.com/josegonzalez/beaver
.. _nxlog: https://nxlog.org/download
.. _logstash: https://www.elastic.co/products/logstash
.. _rsyslog: https://www.rsyslog.com/doc/master/configuration/modules/omhttp.html
.. _native python code: https://github.com/gdestuynder/mozdef_lib
.. _AWS cloudtrail: https://aws.amazon.com/cloudtrail/
.. _some configuration snippets: https://github.com/mozilla/MozDef/tree/master/examples
What should I log?
******************
If your program doesn't log anything it doesn't exist. If it logs everything that happens it becomes like the proverbial boy who cried wolf. There is a fine line between logging too little and too much but here is some guidance on key events that should be logged and in what detail.
+------------------+---------------------------+---------------------------------------+
| Event | Example | Rationale |
+==================+===========================+=======================================+
| Authentication | Failed/Success logins | Authentication is always an important |
| Events | | event to log as it establishes |
| | | traceability for later events and |
| | | allows correlation of user actions |
| | | across systems. |
+------------------+---------------------------+---------------------------------------+
| Authorization | Failed attempts to | Once a user is authenticated they |
| Events | insert/update/delete a | usually obtain certain permissions. |
| | record or access a | Logging when a user's permissions do |
| | section of an application.| not allow them to perform a function |
| | | helps troubleshooting and can also |
| | | be helpful when investigating |
| | | security events. |
+------------------+---------------------------+---------------------------------------+
| Account | Account | Adding, removing or changing accounts |
| Lifecycle | creation/deletion/update | are often the first steps an attacker |
| | | performs when entering a system. |
+------------------+---------------------------+---------------------------------------+
| Password/Key | Password changed, expired,| If your application takes on the |
| Events | reset. Key expired, | responsibility of storing a user's |
| | changed, reset. | password (instead of using a |
| | | centralized source) it is |
| | | important to note changes to a users |
| | | credentials or crypto keys. |
+------------------+---------------------------+---------------------------------------+
| Account | Account lock, unlock, | If your application locks out users |
| Activations | disable, enable | after failed login attempts or allows |
| | | for accounts to be inactivated, |
| | | logging these events can assist in |
| | | troubleshooting access issues. |
+------------------+---------------------------+---------------------------------------+
| Application | Invalid input, | If your application catches errors |
| Exceptions | fatal errors, | like invalid input attempts on web |
| | known bad things | forms, failures of key components, |
| | | etc creating a log record when these |
| | | events occur can help in |
| | | troubleshooting and tracking security |
| | | patterns across applications. Full |
| | | stack traces should be avoided however|
| | | as the signal to noise ratio is |
| | | often overwhelming. |
| | | |
| | | It is also preferable to send a single|
| | | event rather than a multitude of |
| | | events if it is possible for your |
| | | application to correlate a significant|
| | | exception. |
| | | |
| | | For example, some systems are |
| | | notorious for sending a connection |
| | | event with source IP, then sending an |
| | | authentication event with a session ID|
| | | then later sending an event for |
| | | invalid input that doesn't include |
| | | source IP or session ID or username. |
| | | Correctly correlating these events |
| | | across time is much more difficult |
| | | than just logging all pieces of |
| | | information if it is available. |
+------------------+---------------------------+---------------------------------------+ |