Osquery is a powerful tool that allows you to investigate and monitor a myriad of endpoint activity, status, and configuration information through a unified SQL interface. Inside osquery, there's typically a 1:1 correspondence between a source of information and the SQL table you can use to browse or search this information. Some sources of information include parts of the
/proc file system, API calls to container daemons, reading logs or status files on disk, and event streams coming from the Linux audit frame.
In recent times we are seeing an increased number of Docker container malware. Attackers scan the internet to identify the misconfigured Docker engine API installations to install the malicious images or run commands to install the malware. Access to the Docker engine API can provide an attacker fine control over the Docker installation enabling him/her to create, delete, dump and run commands in the containers, although the majority of the malware seen to-date are either using system resources for crypto mining or denial of service attacks. In general, the container is an encapsulated environment to run the application so it can be used for any activity from proxies to botnet services and can easily become part of attacker infrastructure to distribute malware.
Cloud computing is a $136 billion industry, and it continues to grow. As consumers become more technology-savvy, individual use of cloud services enters the realm of convention. Cloud migration is picking up speed because it introduces cost-effective and flexible services into a previously expensive technological sphere. However, cloud computing also gives rise to new security challenges.
It is not often that one runs into situations that so purely fit a classic stereotype. Securing and monitoring Docker containers happens to be one of those conundrums that is a textbook example of a “damned if you do and damned if you don’t” setup. On the surface, securing and monitoring containers seems like a straightforward affair – treat containers like mini virtual machines, and run your security/monitoring agents in each container; or, treat them like processes running on the host OS, and run your security/monitoring agents on the host OS. Sounds simple enough. However, both options run into some surprisingly natty difficulties.