18 Fri 02:00 PM – 07:10 PM IST
15 Thu 03:00 PM – 04:00 PM IST
Accepting submissions till 06 Dec 2021, 11:30 PM
Hasgeek survey; Rootconf Cloud Costs conference announcement The audience research team at Hasgeek has started a survey to understand the Rootconf community better, and what individuals expect from memberships on <hasg… more
Observability, anomaly detection and deep defense is the cycle for early detection of attacks and network breaches.
Speakers from FreeBSD community, CRED, AWS, Datadog, Farsight Securities and other organizations will share their experiences with processes and tools for tightening the loops of network security and anomaly detection, and how to build robust observability workflows.
The conference will cover topics ranging from:
The conference is open for participation to the following practitioners.
See schedule at at https://hasgeek.com/rootconf/detecting-anomalous-network-patterns/schedule
This checklist was developed from the Birds of Feather (BOF) session on Tooling for NSM held on 15 June 2021 under the Anomalous Network Detection Patterns programme. Swapneel Patnekar - Founder at Sreshta IT - and Rashid Feroz - Security Engineer at CRED - shared their experiences and learnings. Anand Venkatnarayan, cybersecurity expert and editor of Privacy Mode and Rootconf progammes moderated the session.
This checklist is compiled by Anwesha Sen, intern at Privacy Mode programme.
Full packet capture has its limitations and cannot be done for the entire infrastructure. It is applicable for a subset of core network architecture.
NetFlow and Zeek: There are many ways to implement NSM in a Data Center (DC) environment. One of them is NetFlow.
DNS can connect the dots with regards to whether there was a security incident or not. There are many ways to find anomalies in DNS. You can put a recursive resolver in your network and look at the DNS responses. (*Here is a link to Swapneel’s presentation on Threat Hunting using DNS at SANOG 37. The slides serve as reference for further details.)
Honeypots can be used to obtain malware samples as well as to generate in-house threat intelligence. You can incorporate Honeypots at very minimal costs in a Cloud-based environment. When the attacker tries to interact with Honeypots, it sends an alert. In For On-premise setups, you can use small appliances like Raspberry Pi.
Correlating connection logs generated by the VPN with Zeek output logs can help you easily figure out who is extracting data from your environment and from where. The destination IP range for dev setup will be different from production.
In a cloud environment, the first thing an attacker will try to do is find an access key and secret key. Place honeytokens within your environment. If anybody uses that pair of access and secret key, you will immediately be notified because those are invalid sets of credentials. You can look for those pairs of access keys using automation by reading logs and cloud trail events, etc. If the attacker gets into your code repository, they will find an access key and try to use it. This helps you to catch them. Similarly, you can place Honeytokens in very obvious places where you would want to catch such malicious activities.
Here is the link to a guide on how to implement honey tokens - https://summitroute.com/blog/2018/06/22/guidance_on_deploying_honey_tokens/
DCs are far harder to secure because of the hardware asset, whereas on the Cloud, you can figure out NSM easily because of the segregation of production accounts, dev accounts, etc. Asset enumeration, which is a problem in the On-premise environment, is generally what leads to problematic network behaviour because the endpoint is insecure. One can see fewer attacks in a cloud environment.
The reason why DCs generally don’t get breached as much as cloud environments is because they’re running in their own private environment. Nothing is exposed to the Internet apart from a single interface which is hosting an application or network. There are a lot of avenues for attackers to get into your network on cloud.