Immutable Security

There are already several good posts out there about decoders and rules, and how one uses both to add new application support in OSSEC. What I haven’t seen is the non-technical process behind adding new apps and making sure it is successful. In this final post for the Second Annual Week of OSSEC, I’d like to share my thought process on the correct way to add new applications.

The first thing to consider is whether or not this will provide enough security value to you for the effort. If these logs ordinarily don’t contain useful information such as authentication attempts, it may not be worth the effort.

Assuming it is worth it, the next thing you want to look for is an authoritative source for all possible logs that the app may generate. This usually means going to the vendor’s web site or asking them directly. Be prepared, however, for the equivalent of blank stares and in some cases, subtle hostility, as they think you must be a competitor trying to pry out some secret sauce.

If you’re lucky enough to find a good source for log entries, you’ll need to spend some time studying them to find the gems and to look for format anomalies. Is the username always in the same place? Are the delimiters consistent? Could a delimiter end up in the user name? More often than not, they won’t be well-formatted and there may even be variations between different versions of the software. As a Mark Minasi book I once read said, “be prepared to learn that documentation lies.”

When writing your decoders and rules, be as specific as possible. Imagine that someone will try to tamper with the logs and break your rules. Make liberal use of the ^ and $ characters, denoting the start and end of strings.  Be specific and avoid the use of regexes such as \. (which means anything) whenever possible.

When writing rules, try to pre-tune them in such a way as to alert the user only when it is important. Generally, this means you only want to alerts on things like policy changes, new privileged users, possible attacks, rare events, and so-on. Consider that two or more seemingly innocuous events combined together could be an attack, so think laterally and creatively. Try to use groups and the info tag in every rule.

Test, test, test. When you think it is perfect, test some more. Try to run them in a live environment for awhile to see how things go. I am certainly guilty of writing some bad decoders and rules, and have learned a lot from the experience. Sometimes the testing might even reveal a bug in OSSEC, or they might work when you test them, but stop working or work differently with another snapshot. So follow up with the anomalies.

Finally, if you think others might benefit, submit them to the project. You might even want to send them to the mailing list first for some peer review. If they’re useful, they may just get included in the next release, which means you will have the satisfaction of knowing you have helped many other people stay safe.

One of the hallmarks of good software is that you can cajole it into doing things it may not have been originally designed to do. Well designed software is small, modular, portable and secure. OSSEC falls into this category.

OSSEC can be run stand-alone or in a distributed architecture with one manager and many agents. But did you know that you could also run multiple, independent instances of OSSEC on one box? Think of them as little OSSEC minions designed to do your bidding.

Why might you want to do this? How about having separate development, test and production instances? How about testing new versions of OSSEC? How about separating different customers from one another, ensuring the log data does not intermix? Whatever the case, it is possible with OSSEC.

Here’s how to install one instance of OSSEC to protect the server on which it is installed, and another which will only monitor remote hosts. Additional remote instances can be installed based on your needs. These steps are designed to be followed on a host without OSSEC installed, but can be easily modified if you already have it installed. The steps are Red Hat/CentOS specific and again, are easily adaptable.

1. Begin by installing a local OSSEC instance (question one from the install script). This will be the installation designed to protect this host.
2. Once the installation has completed, start the installer again. This time, when it detects that you already have OSSEC installed and asks if you want to upgrade, tell it no. You will now be able to choose an alternate location to install your second instance. Install the second instance, but when it asks you if you want to run syscheck and rootcheck, tell it no. We do this so we don’t have competing rootcheck and syscheck scans running. Active response should also be disabled unless you take the extra precaution of ensuring your responses only execute on the agents.
3. Bind the instances to unique IPs. At this point, you have all you need for a local and a remote install. Each will work independently. However, if you want another instance, you’ll need to make another modification to ensure the remote instances each bind to only one IP address. If you already have multiple interfaces, this is relatively simple. If not, simply follow this excellent guide to create an alias off eth0.  Now, go into the <remote> section of ossec.conf in each remote instance and configure the <local_ip> option to point to the correct IP. Make sure each instance points to a unique IP.
4. Replace the default OSSEC init script. Finally, we need a custom init script to manage our minions. For this to work, we’ll take the concept that OSSEC already uses with the /etc/ossec-init.conf file and expand upon it.
   Create the directory /etc/ossec and assign it the proper permissions:

   #mkdir /etc/ossec && chown root.root /etc/ossec && chmod 700 /etc/ossec

   For each remote instance, copy the ossec-init.conf file from the /etc directory relative to the OSSEC instance (e.g. /var/ossec1/etc/ossec-init.conf, to the system /etc/ossec directory, while appending a random string to the end of the filename:

   #cp -a /var/ossec1/etc/ossec-init.conf /etc/ossec/ossec-init-$RANDOM.conf

   Back up and replace the OSSEC init script /etc/init.d/ossec with this one. Make it immutable so it doesn’t get overwritten on new installs.

   #chattr +i /etc/init.d/ossec

One final tip: I find it helpful to modify the maild source for each instance and preprend the subject line with something meaningful. Then, the alerts will come across as something like: Test Environment: 7 – Integrity checksum changed.

That’s it! You now have several OSSEC instances that can be managed individually with the ossec-control.sh script in each instance’s /bin directory, or globally with the system init script.

Just the other day, someone said to me, “How do I tame syscheck? I get all of these alerts right after I patch and it just drives me nuts!” Ok, that’s not really what they said. What they said was, “Who are you and what the heck is syscheck?” But I’m sure you get the idea.

I’m generally not a huge fan of file integrity alerts. In an environment which is patched often, you can be bombarded with them. Then, because of the human tendency to filter out noise, you’ll miss the important stuff. So I generally think you should only get these kinds of alerts when they really matter.

Before we discuss how to deal with patching, let’s do a quick review of how syscheck scans work in OSSEC.

1. OSSEC scans the system and sends the hashes to the manager.
2. The manager then inserts or updates the syscheck database, which is an ASCII file with a name like: queue/syscheck/(agent-name) 1.2.3.4->syscheck
3. You get an alert, unless one of the following is true:
   1. The file hasn’t changed.
   2. The file has changed more than 3 times and <auto_ignore> is set to yes in ossec.conf.
   3. You have ignored the file with the syscheck_control -f option.
   4. You have ignored the file/directory with <ignore> in ossec.conf.
   5. A rule matches on the file and is configured in such a way as to not send you an alert.

So what can you do to not be bombarded with alerts when you patch? There are a few options. These suggestions assume you have real-time syscheck enabled. Just before patching:

1. Clear the database. Execute syscheck_control -u <agent_id>. Only use this option if you are comfortable with not being able to report on file changes for this host using syscheck_control. You can still query the SQL database for file changes if you are using that option, or by using the reporting daemon.
2. Create a rule to ignore the changes. Of course, you probably don’t want to ignore all file changes all the time, so you might use a rule like this to coincide with your patch window:

<rule id=”100000″ level=”5″>
<if_group>syscheck</if_group>
<time>08:00-10:00</time>
<weekday>sunday</weekday>
<match>C:\WINDOWS</match>
<description>Ignore file changes during patch Sunday</description>
</rule>

You could take this one step further by creating a parent rule, which this one is dependent upon, which looks for the event indicating that a patch has been installed. In this case, it might be useful to use the frequency and timeframe options in the dependent rule instead of time and weekday, so as to match a smaller window of time.

3. Let OSSEC auto ignore files that change more than three times. I generally prefer more control and granularity over my environment, and don’t want to be surprised by too much, so I disable this.

These steps are Windows-centric, but can easily apply to other platforms. For Linux systems, you may want to have a yum event as the parent rule and look for changes to something like /bin.

There are some risks. It’s possible that an attacker can modify files in a system directory while you are patching. These rules don’t actually correlate the process which is patching with the process that changed the files, so you’ll want to use a pretty tight time frame.

Finally, I’ll wet your appetite for what OSSEC holds in the future. Using CDB lists, it will be possible to add your pre-approved hashes to a list and have a rule check to see if they are in the list before alerting you. With a central source for trusted hashes, this should be easy to automate.

Update: ddpbsd correctly pointed out that clearing the database will create a new baseline. This means that you won’t get alerted to the next change on existing files, even if they are not in a patched location–a potentially worrisome problem! You’re better off just using rules.

Are you an OSSEC ninja? Do you dress in orange and red and laugh maniacally at all of the frustrated attackers who have tried to take you down? Do you take medication for that condition? Ok, well, best of luck to you. Back to the topic at hand.

Here are some of my favorite tips and tricks. They promise to elevate you to the next level of OSSEC guru-ness, or maybe they’ll just help you solve a problem. Either way, in no particular order of importance:

1. Ensure a clean restart. After you change your local_rules.xml file, execute “ossec-logtest -t” before you restart OSSEC. If it doesn’t complain, you will have no problems restarting. If it complains, OSSEC would not have started successfully (and you would not be analyzing logs until the error was fixed).
2. Set up a simple test case. Not sure if OSSEC should be sending alerts? Set up a testing rule with something not likely to be found in a log:

<rule id=”100000″ level=”8″>
<match>oogabooga</match>
<description>Testing Rule</description>
</rule>

Now test the rule with the logger utility:

# logger oogabooga

3. Monitor thousands of agents. By default, OSSEC will handle up to 256 agents. But there are successful installations with thousands of agents. You simply need to increase one setting in OSSEC.

#cd src; make setmaxagents
#cd ..; ./install.sh

It also helps to increase a few kernel parameters for your system:
# ulimit -n 2048
# sysctl -w kern.maxfiles=2048
# sysctl -w net.core.rmem_default=5123840
# sysctl -w net.core.rmem_max = 5123840

I like to put OSSEC on its own partition and optimize it a bit with the noatime value. For example:

/dev/VolGroup00/ossec /log/ossec ext3 defaults,noatime 1 2

As an added benefit, if something goes crazy and starts sending out millions of logs, it won’t fill up the root partition and take down the entire server.

4. Fire and forget. Normally, the OSSEC manager and agents talk to one another. The manager keeps track of agent status and so-on. If you would prefer to simply have your agents fire off the message to the manager and not have it reply (such as when using a restrictive firewall), try the setoneway option:

#cd src; make setoneway
#cd ..; ./install.sh

Now you can put the manager behind an uber-restrictive firewall and feel like a true security ninja!

5. Create a nicer looking subject. The default OSSEC alert format is a bit verbose. It tells you it is OSSEC in the from field, as well as in the subject and the body. OK, I get it. You’re OSSEC. By doing this:

#cd src; make setfullsubject
#cd ..; ./install.sh

And this:

#cp -a /var/ossec/etc/internal_options.conf /var/ossec/etc/internal_options_orig.conf
#sed ‘s/maild.full_subject=1/maild.full_subject=0/g’ etc/internal_options.conf

The look of your subject line will change from this:

OSSEC Notification – (agent-name) 1.2.3.4 – Alert level 10

To this:

10 – Multiple web server 500 error code (Internal Error). – (agent-name) 1.2.3.4

In the second example, we have the most important information first (the level), followed by a meaningful alert name, then the agent name and IP. This allows you to quickly discern the importance of the alert, and is particularly useful when you have a large number of alerts to read. Just bear in mind that, unless you use the do_not_group option, this one alert subject could represent several different actual alerts in the body of the e-mail.

If you comb through the source code, you might also be able to find some other nuggets worth having. What have you discovered?

Yesterday, I blogged about how we could beat OSSEC up, or, to put it more accurately, the people and protocols behind it. Today, we’re going to discuss how we can fight back against the bullies. For this post to make sense, you’ll need to read the first one. Go ahead, I’ll wait…

Ok. Put your gloves on. Here are some countermeasures and considerations for all of the risks we discussed previously.

1. Alert manipulation. Recall that alert manipulation is the process by which alerts are used against us.
   1. Alert tickling. The idea with alert tickling is to send just enough normal-looking alerts to create a window for the attacker to go undetected. There are a couple of ways to defend against this. One is active response. By default, anything that is level 6 or higher can trigger an active response such as blocking the IP for 15 minutes. The cool thing about active response is that it will continue to work even if your alerts are delayed until the next hour. This means the attacker might still be blocked regardless of when you get the e-mail. Another countermeasure is to increase the default number of alerts per hour to something like 9999. Of course, this opens you up to the next risk of alert flooding. Perhaps the best countermeasure is to configure the do_not_delay option in ossec.conf. Adding something like this would save all e-mails over 12 until the next hour, except for those that appear to be an attack:

   <email_alerts>
   <email_to>secanalyst@example.com</email_to>
   <group>attacks</group>
   <do_not_delay />
   </email_alerts>

   2. Alert flooding. With alert flooding, the attacker would like to swamp you with so many alerts that you just can’t bear to read them all. Besides tuning, the best option to protect against alert flooding is to keep the email_maxperhour setting at a reasonable level. If you choose to go that route, be sure to note the risks that can introduce and plan accordingly.
2. Killing the OSSEC processes. I am a firm believer in the mantra that if someone has administrative access to your system, they can do whatever they want. Ultimately, there is nothing you can do to completely protect against this risk. On the other hand, not all administrative users are savvy enough to be able to subvert the ossec processes. A well-written SeLinux policy just might be enough to hold them back. Also, recall that I talked about the non-malicious attacker. Non-technical safeguards such as background checks, job rotation and common workstation areas might be enough of a deterrent for those situations.
3. Log injection. With log injection, the attacker wants to control the log output. There are two main types of log injection: remote and unauthenticated. They can also be combined for greater efficiency.
   1. Remote log injection. The basic defense against remote log injection is to first assume that all input is malicious. Nothing from the user can be trusted, even if your OSSEC installation is on a private network. The second line of defense is to write your OSSEC decoders in such a way as to restrict where in the message input can be coming from. Referring again to Daniel’s paper, Attacking Log Analysis Tools, we can see that adding a ^ (to denote the beginning of the line) or a $ (to denote the end of a line) is often enough.
   2. Unauthenticated log sources. The obvious countermeasure to unauthenticated log sources is to not use them. However, while that is the best defense, it is rarely practical in a modern network. Sometimes you are simply faced with the choice of getting logs through syslog, or not at all. Given the choice, I would choose to get the logs. One approach is to design an out-of-band network where your unauthenticated network devices can send their logs. That approach is rather expensive and not very pragmatic for most people. The more practical approach is to enable IP spoofing protection on your network devices, such as in this example. Be aware, though, that it may not protect against attacks within the same broadcast domain.
4. Traffic manipulation. This attack can be difficult to prevent. Not only does it involve the direct manipulation of traffic, as is the case with something like ARP poisoning, but also intentional or unintentional flooding. Common countermeasures include NAC protection, blocking DoS attacks upstream and not using unauthenticated log sources.
5. Active response manipulation. Active response can prevent an attack from becoming a breach. It can also enable an attacker to block legitimate traffic. OSSEC accounts for this by giving you the white_list option for use in ossec.conf. Any IP or range added to this option won’t be blocked by active response. Keep in mind that a trusted host may be compromised first, with the attacker looking to elevate the access. The safest option is to not whitelist anything. OSSEC also includes a timeout for responses, so if you are accidentally blocked, you can try again in about 15 minutes.

By now you may be starting to realize that the default configuration of OSSEC is very sane and has taken most of these risks into account. At the same time, it gives you enough flexibility to meet your needs and to make your own risk decision. The important thing is to consider the possible consequences of changing a default setting and be comfortable with the additional risks it may present.

No discussion about the effectiveness of a security monitoring tool would be complete without exploring ways to defeat that tool. While this may seem self-defeating, it is my belief that an honest perspective about strengths and weaknesses of the tools we use leads to better risk decisions and ultimately, better tools.

OSSEC can be abused in a number of ways. Many of those are not the fault of OSSEC, but rather they speak to weaknesses in basic protocols or the analyst using the tool. Here are some of the ways an attacker may try to abuse OSSEC:

1. Alert manipulation. Alerts can be manipulated in a few different ways. The basic idea is to attack the alerting mechanism in such a way as to throw the defender off the trail. Here are a few of those ways:
   1. Alert tickling. By default, OSSEC will send no more than 12 alerts per hour. This is to prevent an attacker from flooding you with a sea of alerts. This leaves the potential for the bad guy to intentionally engage in something, maybe from a different IP, that looks like noise. You’ll chalk it up as nothing to worry about and the attacker will have a window to proceed while being undetected.
   2. Alert flooding. In this attack, the point is to flood you with as many alerts as possible. The attacker may know that you have raised the default number of alerts per hour, and will count on you not reading them all. A savvy attacker will begin the attack with simple stuff that looks like noise, hoping you will read the first few alerts and delete the remaining 1,000.
2. Killing the OSSEC processes. If your attacker is an administrator, then it is easy to simply kill the processes. Anything logged while the OSSEC processes aren’t running will not be sent once OSSEC is restarted. It is valid to say that if one has administrative access, then all bets are off. Understand, however, that not all attackers are outright malicious or untrusted. Your attacker could simply be an administrator who doesn’t want to follow the change control process, and stops OSSEC before making the unauthorized change.
3. Log injection. When the attacker can manipulate the log file to their liking, we call it log injection.
   1. Remote log injection. While SQL injection is well-understood, it’s log-based sister, remote log injection, is not widely discussed. The basic premise is the same. Anything coming from a user should not be trusted, as it could be malicious. As Daniel demonstrates in his paper, Attacking Log Analysis Tools, when the regexes responsible for parsing the message are not well-written, it gives the attacker the possibility to manipulate the log monitoring program in his favor.
   2. Unauthenticated log sources. By default, OSSEC sends all logs encrypted with blowfish. In addition, a counter is added to each log to prevent log replaying (an attack in itself). However, OSSEC also supports syslog, because, well, let’s face it, that’s sometimes the only option. As you may know, syslog messages can be spoofed. Since the protocol is UDP, the attacker does not have to worry about completing the connection. So, if an attacker can spoof the source IP, he can cause you all sorts of grief. For a great example of how to spoof syslog, check out the paper, The Ins and Outs of System Logging Using Syslog.
4. Traffic manipulation. At attacker who can interfere with the traffic between the OSSEC agent and the manager might be able to keep the message from being received. If the message isn’t received, the manager can’t correlate and alert on the log.
5. Active response manipulation. Active response can be a double-edged sword. On one hand, it can prevent an attack from becoming a breach. On the other hand, when combined with unauthenticated log sources, the attacker might be able to spoof traffic and block legitimate hosts from accessing your host.

Understanding the risks leads to the inevitable question, “how do I protect myself?” In part II, we’ll discuss some countermeasures for these attacks, as well as the trade-offs for these countermeasures.

Since version 1.2, OSSEC has generated daily, chained MD5/SHA1 checksums of the alerts log, and if logall is enabled, the archives.log. As Daniel notes in his blog post, this can provide you with a mechanism to prove that a particular log was not tampered with. If you compare a hash that was e-mailed to you with one on the manager, you can reasonably say the log has not been tampered with.

Or can you? What if the e-mail server was on the same network as the manager? What if they were running the same OS version and had the same vulnerability exposure? Can you still say the hash has not been tampered with?

One way to have a high degree of confidence in the integrity of the hash is to get it out to as many people as possible. The more remote, unrelated computers that have a copy of the hash, the higher degree of confidence and non-repudiation in that hash. Since the hash is a one-way function and does not contain the actual log data, the confidentiality of your logs remains intact.

Here are just a few ways this can be done.

• Twitter. Tweet your hashes, maybe even to an account set up especially for this. Make sure they are public. Here’s an example of what I mean.
• Facebook. Set up a facebook page for your hashes and make it public.
• Your web site. Set up a cron job to update a page daily that has all of your hashes. Make sure it gets indexed.

Again, the more unrelated sites that have these hashes, the higher degree of assurance you will have. Although I am not a lawyer, I can imagine a situation where one would make a very compelling argument that the logs were intact, because in order for the other side to repudiate that argument, they would have to prove that all of the external sources were also compromised and the hash modified.

What other ideas do you have for log integrity and non-repudiation? Speak up in the comments!

When many companies think about log management, they immediately jump to SIEMs, or Security Information and Event Managers. You’ll also find many in the infosec community who jump to the conclusion that a SIEM is the right solution for the problem, when they haven’t really even taken the time to set requirements, expectations and understand what it is they are trying to achieve.

I was reminded of this today when a client needed a refresh and storage update of their pre-existing SIEM solution. The quote was $77,000 (USD). They are collecting logs from about 300 servers and running daily reports of successful and failed logins. That’s it.

I couldn’t help to think, what is so special about this solution that they need to spend $77,000 for another log collector appliance (which is really just a Dell server with Windows installed on it) and about 2TB of storage? If they are paying this much for a simple upgrade, what was their initial investment? If it’s like most companies who buy SIEMs, they didn’t get out of the room for under six figures.

To be clear, a good SIEM does more than simply collect logs and allow one to run reports. It can correlate log and vulnerability information, elevate alerts based on asset value, identify suspicious patterns and integrate with ticketing and incident response systems.

The question is: who is sufficiently advanced in their security program to make use of such capabilities? Furthermore, what regulations, contracts or risk programs require this level of sophistication? The answer, based on my experience, is very, very few.

Does that mean having all of this wouldn’t be a good thing? Of course not. In a perfect world, security ninjas would be able to make these things sing and dance in all kinds of cool ways. But most of us don’t live in that world. We live in a world where management gives us conflicting priorities, doesn’t adequately staff the security team and turns down our requests to limit user access.

So I am here to tell you that you probably don’t need a SIEM. And here are the top five reasons why I think so:

1. They are ridiculously expensive. Sure, the cost of security should be commensurate with the risk. But when you’re talking about laying down six or seven figures for a tool, you better be damn sure it is going to pick up your toys and call you sweetheart.
2. The requirements often don’t necessitate it. But I have SoX, HIPAA and PCI requirements! Bah! I have been in all of those environments and, in most cases, a SIEM was nowhere to be found. Most of them had simple syslog servers with daily reports sent out by scripts. They passed the audits just fine.
3. It may never be fully deployed. SIEMs are complex beasts. They are also often buggy, frail and slow. To properly deploy, integrate and test a SIEM can take a team months or even years. The most often line I hear with SIEM administrators is, “We haven’t gotten to that part yet.”
4. They often provide little value. If the cost were high and the value was high, maybe the price wouldn’t be so much of an issue. But the bang for the buck you get is often very low beyond what you could do with a solution that costs one-tenth of the price, or less. I have seen many SIEMs that don’t even alert you to multiple failed logins to a single host. You have to configure these yourself. That means each analyst at each company becomes a research analyst, and has to do their own threat modeling. You should get the experience and expertise of the SIEM vendor from day one.
5. You’ll experience vendor lock-in. Now that you have all of this data in the SIEM, how do you get it out should you want to change course? or will you be forced to pay the piper when you need an upgrade?

Now, obviously, I have come down pretty hard on SIEM vendors here. I expect someone will come along and want to refute my assertions. I most definitely welcome that.

There’s a missing market in the log management world. It lies somewhere between solutions like OSSEC and syslog-ng, and Arcsight. It’s a market which would offer intelligent log collection, analysis, correlation and alerting, combined with valuable reports made available through a nice front-end. And there’s no reason a product like this should cost more than five-thousand dollars, at most.

Note to prospective SIEM employers if I am ever looking for work–just kidding! :)

The OSSEC team is happy to announce the release of v2.5. It comes with lots of interesting features and enhancements.

One of the most interesting, I think, was created by Jeremy Rossi. He added cdb support. What can you do with cdb support? Picture this: you have a list of 10,000 IP addresses that are known to be part of a massive botnet. You think to yourself, “Self, I would really like to detect a connection from any one of these IPs and just block them, but there is no way I am going to write 10,000 rules.” What do you do? Well, with cdb support, you can write one rule and have it reference a list with all of those IPs. And it’s fast. You likely will not notice any difference between a rule with one IP and a rule referencing this cdb list.

My other favorite feature, implemented by OSSEC founder and fearless leader Daniel Cid, is the report_changes option (only for ‘nix currently). Don’t you get frustrated by knowing that a file changed but not knowing what changed in the file? I know I do. Well, with the report_changes option added to your syscheck configuration, OSSEC will now show you the diff of that file, assuming it is ASCII. This is great for places like the web root. Just be sure to exercise caution in what you monitor. It wouldn’t be a good idea to get e-mail diffs of sensitive files like shadow and private keys.

I contributed a new set of Dovecot decoders, a bunch of Windows rules and fixed some Windows installer bugs. I’ll follow up about the Windows rules in another post. On the Team Members section of the site, I am designated as the “Everything Windows-related” guy. Let’s just make one thing clear: I am not a Windows guy, per-se. But that’s where my customers need the most help. :)

Be sure to check out the release. And don’t forget about the upcoming Second Annual Week of OSSEC, otherwise affectionately referred to as 2WoO.

Last year I spoke at a conference on OSSEC and, in celebration, decided to create an entire week of blog posts about OSSEC. It was received pretty well. A few people were even inspired to contribute their own posts.

Well, there are a lot of us out there, and OSSEC is one of those rare communities in the open source world where everyone is respectful and tries to help. So, I thought to myself, “Self, why not make this a community event?”

I am proposing that we have a community “Week of OSSEC” to occur next month, October 17-23. October is aptly named National “Cyber Security Awareness Month,” so I think it’s a good fit.

How can I help? What can I contribute, you say?

-Spread the word
-Blog about OSSEC – how do you find it useful? What tips and tricks do you have?
-Find, report, and/or fix bugs
-Brainstorm ideas on how we can make OSSEC better. What kinds of rules should we have? What additional functionality is needed? What research can we incorporate to better detect attacks?
-Help with documentation (this one is huge!)
-Submit some code, a patch, or a new feature
-Tell us a story about what makes it difficult. What rules constantly fp?
-Proudly wear your OSSEC shirt if you have one. Send in a pic. Bonus points for standing next to a commercial SIEM-type booth. :)
-More..

The idea is simple: if everyone contributes just a little–even if you don’t think the contribution matters much, then we will have helped one another immeasurably. And isn’t that what free software is all about?