Dark Reading is part of the Informa Tech Division of Informa PLC
This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Everything You Need to Know About DNS AttacksIt's important to understand DNS, potential attacks against it, and the tools and techniques required to defend DNS infrastructure. This report answers all the questions you were afraid to ask.
Domain Name Service (DNS) is a critical part of any organization's digital infrastructure, but it's also one of the least understood. DNS is designed to be invisible to business professionals, IT stakeholders, and many security professionals, but DNS's threat surface is large and widely targeted.
Attackers are causing a great deal of damage with an array of attacks such as denial of service, DNS cache poisoning, DNS hijackin, DNS tunneling, and DNS dangling. They are using DNS infrastructure to take control of inbound and outbound communications and preventing users from accessing the applications they are looking for. To stop attacks on DNS, security teams need to shore up the organization's security hygiene around DNS infrastructure, implement controls such as DNSSEC, and monitor DNS traffic
Incident Readiness and Building Response Playbook
In this special report, learn the Xs and Os of any good security incident readiness and response playbook.
Tweet This
1 Comments
User Rank: Author
2/8/2019 | 4:50:01 AM
Your only chance of actually controlling network connectivity is by deploying the function inside a VPC and then running a NAT gateway or a virtual firewall on an EC2 instance, but then, you have to deal with a new set of problems, not to mention that you just "de-serverlessed" (I need to trademark this term) the application.
There are alternatives to VPC, especially around outbound networking - you could use a library like FunctionShield (free), which enables you to regain controls over where/who/what the function can communicate with (proper disclosure - my team developed that library). More information on the github project: https://github.com/puresec/FunctionShield/
To your last point - application/business layer security should always remain the responsibility of the application owner, both because of liability, but also because the owner is the only one who really understands the business logic.
FaaS platforms will evolve to be more intelligent and tailored to specific use cases, and together with serverless-native app security solutions and cloud-native mind-set, I'm certain that the overall security posture is about to get a serious boost.