One Article Review
| Source |  taosecurity |
|---|---|
| Identifiant | 1085953 |
| Date de publication | 2019-03-28 16:40:01 (vue: 2019-03-28 22:00:50) |
| Titre | Thoughts on OSSEC Con 2019 |
| Texte |  Last week I attended my first OSSEC conference. I first blogged about OSSEC in 2007, and wrote other posts about it in the following years.OSSEC is a host-based intrusion detection and log analysis system with correlation and active response features. It is cross-platform, such that I can run it on my Windows and Linux systems. The moving force behind the conference was a company local to me called Atomicorp.In brief, I really enjoyed this one-day event. (I had planned to attend the workshop on the second day but my schedule did not cooperate.) The talks were almost uniformly excellent and informative. I even had a chance to talk jiu-jitsu with OSSEC creator Daniel Cid, who despite hurting his leg managed to travel across the country to deliver the keynote.I'd like to share a few highlights from my notes.First, I had been worried that OSSEC was in some ways dead. I saw that the Security Onion project had replaced OSSEC with a fork called Wazuh, which I learned is apparently pronounced "wazoo." To my delight, I learned OSSEC is decidedly not dead, and that Wazuh has been suffering stability problems. OSSEC has a lot of interesting development ahead of it, which you can track on their Github repo.For example, the development roadmap includes eliminating Logstash from the pipeline used by many OSSEC users. OSSEC would feed directly into Elasticsearch. One speaker noted that Logstash has a 1.7 GB memory footprint, which astounded me.On a related note, the OSSEC team is planning to create a new Web console, with a design goal to have it run in an "AWS t2.micro" instance. The team noted that instance offers 2 GB memory, which doesn't match what AWS says. Perhaps they meant t2.micro and 1 GB memory, or t2.small with 2 GB memory. I think they mean t2.micro with 1 GB RAM, as that is the free tier. Either way, I'm excited to see this later in 2019.Second, I thought the presentation by security personnel from USA Today offered an interesting insight. One design goal they had for monitoring their Google Cloud Platform (GCP) was to not install OSSEC on every container or on Kubernetes worker nodes. Several times during the conference, speakers noted that the transient nature of cloud infrastructure is directly antithetical to standard OSSEC usage, whereby OSSEC is installed on servers with long uptime and years of service. Instead, USA Today used OSSEC to monitor HTTP logs from the GCP load balancer, logs from Google Kubernetes Engine, and monitored processes by watching output from successive kubectl invocations.Third, a speaker from Red Hat brought my attention to an aspect of containers that I had not considered. Docker and containers had made software testing and deployment a lot easier for everyone. However, those who provide containers have effectively become Linux distribution maintainers. In other words, who is responsible when a security or configuration vulnerability in a Linux component is discovered? Will the container maintainers be responsive?Another speaker emphasized the difference between "security of the cloud," offered by cloud providers, and "security in the cloud," which is supposed to be the customer\ |
| Envoyé | Oui |
| Condensat | 2003 2007 2018 2019 about accelerate acquire across active ahead almost analysis another antithetical apparently are aspect astounded atomicorp attend attended attention aws balancer based become been behind bejtlich between blogged blogspot brief brought business but called can chance cid cloud com company competition complete component con conference conferences configuration considered console container containers continue cooperate copyright correlation country create creator cross customer customers daniel day dead decidedly delight deliver deployment design despite detection develop development did difference differentiation directly discovered distribution docker doesn during easier effectively either elasticsearch eliminating emphasized engine enjoyed environment even event ever every everyone example excellent excited expect features feed first following footprint force fork forward free from future gcp github goal going google had has hat have highlights his host however http hurting includes informative infrastructure insight install installed instance instead interest interesting intrusion invocations jitsu jiu keynote kubectl kubernetes last later learned leg legal like linux load local log logs logstash long longer look lot made maintainers makes managed many match mean meant memory micro monitor monitored monitoring more moving nature new nodes not note noted notes offer offered offers one onion ossec other output outsource perhaps personnel pipeline planned planning platform point posts presentation problems processes project pronounced provide providers ram really red related replaced repo response responsibility responsible responsive richard roadmap run saw says schedule second secure security see sense servers service services several share skills small software some speaker speakers stability standard successive such suffering supposed system systems talent talk talks taosecurity team technical tenable term testing think third those thought thoughts tier times today track transient travel uniformly uptime usa usage used users view vulnerability watching way ways wazoo wazuh web week what when whereby which who will windows words worker workshop worried would wrote www years |
| Tags | Vulnerability |
| Stories | Uber |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.