Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ă„hnlich wie Security for Complex Networks on AWS
Ă„hnlich wie Security for Complex Networks on AWS (20)
Mehr von Teri Radichel
Mehr von Teri Radichel (17)
KĂĽrzlich hochgeladen
KĂĽrzlich hochgeladen (20)
Security for Complex Networks on AWS
- 1. Security for Complex Networks on AWS Teri Radichel | @teriradichel WatchGuard Technologies
- 5. Story Of A Breach
- 6. The Network Doesn’t Lie
- 11. Port Scan
- 15. EC2 EC2 EVIL INTERNET Every Host Accessible From Internet: Bad
- 16. 70.70.70.70 10.0.3.010.0.1.0 10.0.2.0 XNO ROUTE FOR 70.70.0.70 WEB APP DATAEVIL Subnets and Route Tables
- 17. WEB APP DATAEVIL ALLOW OR DENY TRAFFIC 70.70.70.70 10.0.3.010.0.1.0 10.0.2.0 Subnet NACLs X
- 18. Tips for Subnets • Keep subnets as big as possible • Have to track CIDRS, changes, fix conflicts, firewall rules inside/outside AWS • Too many - Run out of IP Space • Too small – reallocation takes down applications • Understand where data can flow based on Route Tables • Limit routes to what is required • Limit Internet Gateway Routes • NACL rules are limited to 20. Use for broad rules that always apply.
- 19. WHITE LIST XEVIL RESIDE ON HYPERVISOR TRAFFIC IN THE SAME SUBNET Security Groups
- 20. Structuring Security Groups • A group of rules, not a group of instances • Whitelist • Use security group IDs in rules whenever possible • Abstract out common rules • – and only common rules (DNS, AD, Amazon IPs) • Security group rules are limited • Consolidate contiguous CIDR blocks into a single rule • Check what ports products require prior to purchase • May need to re-architect to get around limits Common App Specific
- 21. 70.70.70.70 10.0.3.010.0.1.0 10.0.2.0 WEB APP DATAEVIL 70.70.70.70 ALLOWED ON PORT 80 10.0.1.0 ALLOWED ON PORT 8080 10.0.2.0 ALLOWED ON PORT 3389 An Example. We’re Good, Right?
- 22. 70.70.70.70 10.0.1.0 EVIL Proxy VICTIM 10.0.1.0 ALLOWED ON PORT 80 PROXY TRAFFIC AS 10.0.1.0 Proxies send traffic that originated from blocked hosts via software on allowed hosts and ports Not quite. About Proxies…
- 23. THIS TRAFFIC WOULD BE OTHERWISE BLOCKED LOOKS LIKE HTTPS ON PORT 443 TO FIREWALL …ALLOWED Proxies and Tunnels Proxies wrap disallowed traffic in allowed protocols and communicate on allowed ports
- 24. Only Allow Direction You Want • For a given data flow: • Is it initiated inside your network? • Outside your network • Or both? • If only one direction, block the opposite direction • Traffic is initiated to typically on lower numbered ports • Responses are generally on higher numbered ephemeral ports • Security Groups are stateful, always allowing response to sender • NACLs can ALLOW or DENY explicitly including response traffic
- 25. APP PORTS FOR REQUEST e.g. HTTPS 443 Amazon Linux: 32768-61000 ELB: 1024-65535 Windows Server 2008+: 49152-65535 NACLS and Ephemeral Ports WEB X EVIL NACL BLOCKS 443 OUT EPHEMERAL PORTS FOR RESPONSE
- 26. Look for DENY log entries • Block host to host traffic inside your network unless required • Turn on VPC Flow Logs • Look for DENY traffic to indicate a host is misbehaving • Valid applications should never generate a DENY log entries • Use other tools for more in depth analysis if needed • VPC Flow Logs has some limitations
- 27. Other Potentially Problematic Patterns • Traffic from countries with whom you do not do business • Excessive connections over time • Many connections in quick succession • Excessive connection length • Excessive data in or out • Encrypted connections via unknown keys • Traffic to honey pots < Only run these in air-gapped accounts
- 28. More Considerations • AWS Services You Choose – Do they leave the VPC? • NTP • DNS • Active Directory • Proxies • Amazon IP Ranges • Installing software packages – secure access to repositories • Backhauling traffic • Data transfer costs
- 29. Is it easier to patch all your hosts? Or block a traffic to a network port? Depends on your network.
- 30. Understand paths traffic can take. Data is like water. Open a hole - it will flow there.
- 31. Limit Entry and Exit Points
- 32. SECURITY CHECK PROTECTED HOST NO INTERNET ROUTE WAF NAT HTTP/S PROXY IDS/IPS DLP UTM/NGF BASTION API GATEWAY DEPLOY SYSTEM DDOS (SHIELD) INTERNET ROUTE Deploy Security Controls at Entry + Exit Points X X EVIL
- 33. Transit VPC • Less connections vs trying to connect every network • Easier to manage a single point of intersection • Capture traffic crossing boundaries • Extra protection and inspection at this point
- 34. IF A CONTROL CAN BE CHANGED BY ANYONE, THE CONTROL IS USELESS • Root Company Account • AWS Organizations • AD + MFA • Roles + Policies • Developers are rarely network security professionals • ^ That could change! • Security team for network changes, transit VPC
- 35. Implementation Bottlenecks ~ Some Tips • If network deployments become bottlenecks there will be a revolt • Create rules that people can understand and follow • Create common network patterns: WAF > Web > App > DB • Don’t throw network implementation over the wall to developers • Have app developers present to test networking when deployed • QA / pen test your networking implementation (follow AWS rules) • Allow developers to propose changes such as GitHub fork • Automate ~ wisely!
- 36. Accounts and VPCs • Design accounts, VPCs and subnets to limit entry and exit points • Break into separate accounts for: • Groups with different permissions: teams, line of business, departments • Sandbox (Air-gapped) • Lift and shift not matching security standards and policies • Separate environment to limit PCI scope, HIPAA, PII • Consider peering connection costs and route implications
- 37. SDLC: Dev, QA, Staging, Prod DEV QA PROD CI/CD Check In Code Deploy • Separate accounts for separate teams • Test deployments • Different levels of network access • Embedded security checks Staging Deploy Deploy Deploy
- 38. Direct Connect or VPN • Use VPN or Direct Connect between regions and locations • Direct Connect = private line, less issues with latency – Data Center • VPN = encrypted tunnel for traffic to traverse instead of going over the Internet more exposed • An IPSEC VPN is at layer 3 – less information for attackers; VPN endpoints must be secured. • SSL is layer 7. Exposes more information in unencrypted portions of packet header. Must secure every SSL endpoint. End to end. • Use both IPSEC + HTTPS APIs for private traffic if possible.
- 39. An IBM report finds that human error contributes to 95% of all security breaches.
- 40. Secure and Automated Deployments Public ENI on eth0 security group Private ENI on eth1 security group Availability Zone Lambda function for CLI Commands security group Elastic IP Private Management Subnet No public Internet Access Network Access for Firebox Configuration Only Public Subnet IGW in Route Table Public ENI Public IP (EIP) Bucket for Lambda and EC2 Key for Firebox CLI Firebox Cloud Port 4118 Bucket Policy Port 4118 https://github.com/tradichel/FireboxCloudAutomation S3 Endpoint
- 41. Event Driven Security • Example: honey pot and event driven incident response • Balancing Security and Innovation with Event Driven Automation • https://www.sans.org/reading- room/whitepapers/incident/balancing-security-innovation-event- driven-automation-36837 • Github: • https://github.com/tradichel/AWSSecurityAutomationFramework
- 42. Reporting & Monitoring • VPC Flow Logs, CloudWatch • Logs in S3, Databases • ElastiSearch • QuickSight • Third Party Tools • AWS Marketplace • Cloud Services • SIEM (Splunk, Graylog) • Get Help (MSSPs) WatchGuard - Dimension
- 43. Packet Capture • Packet Capture is Possible, but must be done differently • Will be publishing a paper on this shortly…
- 44. Collective Data
- 45. Thank you! • Teri Radichel • Director of Security Strategy & Research • WatchGuard Technologies • @teriradichel – DM me if questions • If you cannot see my tweets send a note to @support on twitter • Slides: https://www.slideshare.net/TeriRadichel
- 46. Related AWS Videos • Billion Packets: • https://www.youtube.com/watch?v=St3SE4LWhKo • One To Many: • https://www.youtube.com/watch?v=3Gv47NASmU4 • VPN/Direct Connect • https://www.youtube.com/watch?v=Qep11X1r1QA • VPN/Direct Connect • https://www.youtube.com/watch?v=SMvom9QjkPk • Connecting Datacenters • https://www.youtube.com/watch?v=F2AWkGem7Sw
Hinweis der Redaktion
- 1
- 2
- Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon https://www.amazon.com/Countdown-Zero-Day-Stuxnet-Digital/dp/0770436196
- Spam Nation: the Inside Story of Organized Cybercrime-from Global Epidemic to Your Front Door https://www.amazon.com/Spam-Nation-Organized-Cybercrime-Epidemic/dp/1492603236/ref=pd_lpo_sbs_14_t_2?_encoding=UTF8&psc=1&refRID=8VFF3N8AHKHXED96KR7A Brian Krebs’ blog: https://krebsonsecurity.com
- The story of my compromised hostel booking engine…
- Just as my server was not telling me it was compromised, your hosts could be compromised and report false information. The malware in my case was likely not that hard to spot by a security professional, but now malware exists that are much more stealthy. A kernel mode root kit will embed itself in the kernel of your operating system and at that point it can modify the information your computer is reporting to you – from processes to memory to what files exist. The only way to get rid of it is to wipe the whole machine and start over. http://resources.infosecinstitute.com/rootkits-user-mode-kernel-mode-part-2/ The Blue Pill will basically turns your machine into an instance on a hypervisor and has full control of your host and the information reported to it from the underlying hardware. https://en.wikipedia.org/wiki/Blue_Pill_(software) The network on the other hand, must have some level of truth otherwise it wouldn’t function.
- Imagine you are sending a letter to a friend. If you don’t put the return address on it and your friend didn’t know your address, your friend wouldn’t be able to respond, and you wouldn’t get the letter back if it couldn’t be delivered. If you didn’t put the correct address for your friend on the letter, the letter wouldn’t get to it’s intended destination. If you didn’t put the contents you wanted your friend to receive inside the envelope the letter would be useless.
- Network packets are the same way. These blog posts provide information to convert the above packet in HEX to a human readable form – but for more information take a security class such as the SANS security boot camp and network intrusion detection classes. http://websitenotebook.blogspot.com/2014/03/ip-internet-protocol_1.html http://websitenotebook.blogspot.com/2014/05/hexadecimal-to-binary-to-decimal-cheat.html Every packet has a source and destination address and a payload or the intended data for the recipient. If the destination address is wrong, the packet won’t get where it needs to go. If the payload is incorrect, the packet won’t serve it’s intended purpose. If the source address is incorrect the responses won’t get back to the sender (which in the case of a DDOS attack may be the goal, but for normal traffic it is not). Of course attackers can obfuscate the data and try to bypass security appliances and avoid detection, but in the end if you have all the packets, you can see what was sent and received and put the pieces back together. This is why I say: The network doesn’t lie.
- Let’s look at some random network traffic. I started up a WatchGuard Firebox Cloud in a test VPC and put it on the Internet. Within a day I had a large amount of traffic hit it from all over the Internet. I did not advertise this host in anyway. This traffic could be malicious or accidental. I put a random sample of the traffic on my blog and spent a short time looking at it and making some notes. You can go to the above web site to see this blog post on 5/21/2017. The traffic shows that hosts from all over the world are trying to connect to my firebox on different ports. Who owns all these hosts? You will noticed the traffic is grouped under headings that link to web sites. The first one is APNIC. Let’s take a look at that…
- Different regional registries allow you to up the owner of an IP address on these web sites. The links are all on my blog post and you can read more about them here: https://www.arin.net/knowledge/rirs.html The first link is APNIC, which contains IP address assignments for the Asia Pacific region: https://www.apnic.net If you put an IP address in the search box and hit Search, the results will tell you the owner of a particular IP address and the complete related range of IP addresses. This would allow you to block that range of IPs if it is sending unwanted traffic your way. In Spam Nation, Brian Krebs talks about particularly bad networks that ran most of the nefarious traffic at the time. I figured this out by watching my logs and had blocked various networks completely from accessing my web servers. The book confirms my suspicions about the networks and their activities. Today the traffic is much more distributed, but you still may find that you want to find out more information about an IP address block certain networks from accessing the hosts on your network. Some tools also provide this information to you as part of their feature set such as WatchGuard Total Security which has IP Address Identification and Geo-Blocking.
- Here’s some interesting traffic. A single IP address is trying to access my Firebox on a number of different ports. Why would anyone do this? This is called a port scan. Attackers will scan other hosts looking for open ports. Once they find an open port they will try to attack the software behind it with known vulnerabilities for the suspected traffic.
- Once the attacker finds an open port, they will attempt to infect the target host. If the host is infected in many cases the first thing the malware will do is “Call Home”. Malware will talk back to the attacker server to tell it that it is infected so the attacker machines can take further action once they have a foothold inside that host – and your network. Note that ransomware could be different, in that it would simply display a ransom note and no further outbound communication would ensue. But even in the case of WannaCry the malware communicated back out to the Tor network.
- Once a machine is infected, the attacker will use it to scan the surrounding network to find other hosts that have open ports and vulnerable software. The process is repeated until the attacker finds something useful and potentially exfiltrates data from the network or changes in some desired way, such as an attack that manipulated the accounting records at financial firms in ways that normal reconciliation processes did not detect until millions of dollars were stolen.
- So pretty soon we have a whole mess of computers that have been compromised and are talking to each other over the Internet and attacking other computers. A botnet is a group of computers infected with malware from a particular attacker will talk back to what is called a command and control or “C2” server. The infected computers controlled by the attacker are called ”zombies” or ”bots”. The attacker uses these servers to perform various illegal activities. So are all these computers the attackers computers? No. They are your computers and my computers, under the attacker’s control.
- Here is a bad example. This is called a “flat network” where everything resides in a single subnet. Every host is accessible from the Internet directly in this picture. If there were no network rules and no security appliances blocking traffic, every host would be directly on the Internet being bombarded with traffic similar to what hit my Firebox Cloud on the previous slide. Not only is this poor security the extra load on your hosts will cost you more money if you have an Elastic IP Address on these hosts as you will incur data transfer fees. You may also need to scale up to a larger EC2 instance to handle the load.
- Here’s an example using subnets and routes to limit access to certain hosts. This is a typical three tier web application with the web server accessible from the Internet. The web server talks to an application server. The application server talks to a data store. The web, application and database instances are in three separate subnets. The only subnet that has a route to the internet is the web subnet. That means no traffic can go directly to or from the Internet to the application server or the database. In this case the evil server can only directly attack the web server. The application subnet only has routes to the web and data subnets. The data subnet only has a route to the application subnet.
- In addition to defining routes NACLs (Network Access Control Lists) can be used to create rules which allow or deny traffic to a particular subnet. NACL rules are stateless which means rules must be set in both directions (inbound and outbound) as needed. Sample NACL – all traffic allowed in on port 80. Return traffic allowed on ports 1024-65535.
- Based on personal experience and a great presentation by AWS Solution Architect, Rob Alexander: One To Many – Evolving VPC Design https://www.youtube.com/watch?v=3Gv47NASmU4 Keep subnets as big as possible Have to track CIDRS, changes, fix conflicts, firewall rules inside/outside AWS Too many - Run out of IP Space Too small – reallocation takes down applications Understand where data can flow based on Route Tables Limit routes to what is required Limit Internet Gateway Routes NACL rules are limited to 20. Use for broad rules that always apply.
- Security Groups are similar to host based firewalls except they are better – they reside outside the host. That means any malware on the host cannot change them. Security groups will block traffic from outside and inside the subnet. Use a whitelist for Security Groups and only allow what is required for the host protected by the security group.
- Tips for structuring security groups: The name “security group” can be misleading. A security group is not a group of instances, it is a group of rules. A group of rules can be applied to multiple instances. The instances in a single group will not be able to connect to one anther unless a rule is created that allows them to do so. Rules should be a whitelist, meaning only allow exactly what is required. Use security group IDs wherever possible. CIDRs change. Group IDs are easier to manage. Rather than repeat the same rules over and over in every group, abstract out the common rules and apply multiple security groups to your instances. Then when a common rule changes you don’t have to change it in every security group. Active Directory and DNS ports will likely be in a common security group. Security group rules are limited. Use strategies such as changing the architecture or consolidating contiguous CIDRs to a single rule to limit the entries required.
- So we have created multiple subnets, different routes, set up NACLs to create broad rules that don’t change and whitelisted only the minimum required traffic in our security groups. We’re good right?
- Not exactly. Malware that gets onto hosts in the Internet connected tier of your network will attempt to install proxy and other malicious software to tunnel through the open ports on your network to reach other hosts. Proxies on an infected host make it appear to the firewall that the traffic is acceptable and coming from an allowed host. These proxies will be used to tunnel into your network, and exfiltrate data out. Other malicious types of tunnels were used in the Target breach which you can read about here: https://www.sans.org/reading-room/whitepapers/casestudies/case-study-critical-controls-prevented-target-breach-35412
- A proxy will basically wrap some type of disallowed traffic in an allowed protocol. The traffic that would otherwise be disallowed looks OK to your firewall, and that traffic passes right through. In addition to proxies we have to worry about other methods of tunneling data over the network such as reverse shells, packet fragmentation, and protocols manipulated to put the wrong data in the wrong packet header fields to slip it through security appliances. In the case of Target, malformed ICMP packets were used to move data over the network. Data was sent via FTP to hosts all over the world including Florida and Brazil. So what can we do?
- In some cases proxies will need more than a firewall to block or detect, but one thing that will help would be to make sure traffic is only allowed in the direction required. If you only accept web requests inbound to your web server and your web server will never send a web request out to another server, disallow the outbound initiated traffic. Many people make the mistake of thinking that a port opened inbound needs to be opened outbound when traffic is blocked. Typically this is not true. Many common protocols allow traffic in on one port and send responses outbound on ephemeral ports, which are the higher numbered ports. Since security groups are stateful they will always allow the response from traffic that passed through is successfully. Return traffic cannot be blocked. NACLs can be used to explicitly define the ports allowed in and out of a subnet.
- In this example, a subnet NACL could be set up which allows traffic in on certain low numbered ports required for web applications such as port 443. The outbound rules would only allow the higher ephemeral return ports. This would make it impossible for an infected host to initiate outbound traffic on low number ports. http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html#VPC_ACLs_Ephemeral_Ports Infected hosts cannot be used to scan other hosts outside the subnet on the common lower numbered ports. For example in the case of Wannacry the ransomworm infected other hosts using port 445 and in our example above it would not be possible to infect other hosts over the network using that port. Even better, restrict outbound ports to explicit networks when possible, but in the case of a public web server this is not possible.
- If network rules have been set up as a whitelist, turn on VPC flow logs. Look for DENY traffic in network rules. There should be no DENY entries unless something malicious is happening or a host is misconfigured. If a particular host is initiating unexpected DENY traffic in your VPC flow logs, chances are it is compromised. Other tools can be used for deeper inspection, as will be explained in later slides. Note VPC Flow Log limitations. The following types of traffic are not logged: Traffic generated by instances when they contact the Amazon DNS server. If you use your own DNS server, then all traffic to that DNS server is logged. Traffic generated by a Windows instance for Amazon Windows license activation. Traffic to and from 169.254.169.254 for instance metadata. DHCP traffic. Traffic to the reserved IP address for the default VPC router. For more information, see VPC and Subnet Sizing. http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html#flow-logs-limitations
- Anomalous traffic patters can be used to spot unwanted traffic. This slide lists some patterns that may indicate a host is compromised, on your network or someone else’s.
- AWS NTP: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html AWS DNS: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html Active Directory Options: ADFS works with console, CLI and logging into instances. Other options are more limited. Host ADFS server in AWS. https://aws.amazon.com/directoryservice/ https://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/ http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html https://support.onelogin.com/hc/en-us/articles/201174164-Configuring-SAML-for-Amazon-Web-Services-AWS-Single-Role AWS IP Ranges: http://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html Data Transfer for EC2: https://aws.amazon.com/ec2/pricing/on-demand/ Using WatchGuard Firebox for NTP Server http://www.watchguard.com/help/docs/fireware/11/en-US/Content/en-US/basicadmin/NTP_server_enable_add_c.html
- Let’s say you have 10,000 hosts on your AWS network. Are you sure they all have the most up to date software for every single application you are running? Do you even know what is on all of the hosts? For all the organizations infected by WannaCry, do you think it was easier for them to patch all their out of date computers, or simply block port 445 from reaching internal hosts? That depends on the architecture of their network.
- Traffic will flow on the network wherever it is allowed to flow. One incorrectly configured traffic rule can allow data to flow to the wrong place. In one case, two VPCs were connected and the result was application failure because traffic began flowing over the peering connection in unintended ways – because it could. If you don’t have a good handle on all your traffic routes, the result could be traffic flowing to places it should not be.
- Castles typically have one entry over a bridge, a moat and through a very strong door. There are guards on top looking down at anyone entering and exiting. The door is very well protected and monitored. Generally if someone wanted to get into the castle, they have to enter or exit through that door. Structure your network the same way, with limited entry and exit points to and from the Internet, with strong defenses and monitor closely. This is not the only control but this is the most basic thing that many companies are not doing, and then find security extremely difficult to manage.
- At each entry and exit point where malware can get from the Internet into your account, or data can be exfiltrated, employ a security appliance or service of some kind to inspect the traffic. This is not the only place to inspect traffic but you’ll have to start somewhere. The slide lists various types of security tools and appliances, not all of which can be covered in this presentation. If you want to learn a lot more about different types of security tools you can run on your network I highly recommend taking classes at SANS Institute, starting with the security boot camp: https://www.sans.org All of these tools can inspect, limit and log traffic to and from your network. Put some form of security between the Internet and the hosts on your network that will protect them.
- AWS Solution Architect, Rob Alexander, has a great presentation for connecting many VPCs. One To Many – Evolving VPC Design https://www.youtube.com/watch?v=3Gv47NASmU4 In addition to making connections easier to manage, this architecture can limit the entry and exit points to and from different networks and inspect traffic as it crosses boundaries at this point. You may want to set up a separate account that is managed by security and network professionals for inspecting traffic at this point. However as noted with proxies above – if you put other things in this account and the network is not set up correctly traffic may be able to bypass security appliances. The example on the AWS web site uses Cisco gear but you could use other products as well – such as WatchGuard Firebox Clouds.
- So you’ve set up this awesome network and it’s well-architected and very secure. How are your IAM policies looking? Is an IAM profile used for hosts that configure the network? Can anyone run an instance with that profile? That means they can change the network. Can anyone run an instance in the secure subnet from which you access your security appliances? Then anyone can access your security appliances. Think through your account structure and IAM permissions, and your deployment processes, to keep your bright, shiny, new secure network in tact.
- A few tips after setting up networking for 70+ VPCs for a large organization, and defining a network architecture from the ground up for another company...
- Structure your accounts and VPCs for ease of management and security. Tags are great but not easy to enforce. Multiple accounts are simpler to manage for assignment of roles and consolidated billing. Separate accounts for critical data can be more easily locked down, audited and monitored. Scope of PCI audits can be limited. Though audits and compliance do not equal security, the time and cost to audit may be reduced. The subset of people who can access sensitive data can be more easily limited if it is in a separate account. When separating networks into different VPCs, consider the cost of peered traffic. On the other hand, that cost can be compared to the cost of a security breach.
- Accounts can be implemented along the lines of an SDLC (Software Development Life Cycle) process. In each stage of the process there are separate activities, permissions and tools. These stages could be broken down into multiple VPCs or multiple accounts depending on your budget. Deployment tools need to access all environments which means they pose a greater security risk. They can be pulled out into their own VPC and managed by a team that understands the security implications. In the case of Target the system used to deploy updates to the POS machines was used to quickly deploy malware and steal a large number of credit cards in a short amount of time. Secure your deployment system! https://www.sans.org/reading-room/whitepapers/casestudies/case-study-critical-controls-prevented-target-breach-35412 You can also use your deployment system to monitor what is going into your account and perform security checks, as noted on a previous slide.
- Use a Direct Connect or VPN to protect traffic to and from remote locations. A Direct Connect is a private line between your network and AWS. Traffic will not traverse the Internet so will not be subject to certain attacks and latency. Depending on the amount of traffic it may be more cost effective. A VPN will encrypt traffic traversing the Internet between two regions or AWS and a remote location when a Direct Connect is not possible. A WatchGuard firewall could be used both to create the VPN or Direct Connect connection and inspect the traffic at the same time.
- https://media.scmagazine.com/documents/82/ibm_cyber_security_intelligenc_20450.pdf
- Speaking from experience, automated deployments implemented correctly will be more secure. It will take more time to automate and test, but this is the cost of security. For more information refer to these blog posts: https://www.secplicity.org/tag/security-automation/ https://www.secplicity.org/2017/05/04/cloudformation-benefits-secure-aws-deployments/ http://websitenotebook.blogspot.com/2017/05/manual-aws-console-updates-when-using.html Sample code for automated deployment of a WatchGuard Firebox Cloud: https://github.com/tradichel
- AWS facilitates event driven security, which allows security teams to automate security responses and react more quickly to common incidents and events. In addition security checks can be embedded into deployment processes to prevent security problems before they occur. More information: https://www.sans.org/reading-room/whitepapers/incident/balancing-security-innovation-event-driven-automation-36837
- As Dr. Eric Cole says in the SANS Institute Security Bootcamp, ”Prevention is ideal, detection is a must.” Organizations will be breached. The test is how quickly the breach is spotted and the problem is remediated. The recent OneLogin breach was unfortunate but the good news is the attack was spotted quickly and resolved. In the past years the Verizon Data Breach reported that organizations were breached for an average of 11 months before realizing and often that realization came via a knock on the door from the FBI. In order to know when malicious activity is occurring, tools must be used to monitor the traffic and professionals must be trained to spot problems and respond to alerts. For companies that do not have enough security professionals on staff, MSSPs or managed security service providers can help install security appliances and monitor networks. WatchGuard works with a number of partners who perform these services for their customers. The image on this slide is WatchGuard’s award-winning network monitoring tool, Dimension: https://www.watchguard.com/wgrd-products/watchguard-dimension
- AWS facilitates event driven security, which allows security teams to automate security responses and react more quickly to common incidents and events. In addition security checks can be embedded into deployment processes to prevent security problems before they occur. More information: https://www.sans.org/reading-room/whitepapers/incident/balancing-security-innovation-event-driven-automation-36837
- In order to combat the deluge of traffic on the network performing malicious activities, the good guys need to band together and help each other out! A single line in a network log might not mean much but when correlated over many different networks and hosts it could help pin down malicious activities and help stop them before excessive damage occurs. Many companies and organizations perform threat intelligence and reporting activities. Here are a few: The Verizon Data Breach Report is a well known report that reports on breaches across different industries and organizations: http://www.verizonenterprise.com/verizon-insights-lab/dbir/2017/ The SANS Internet Storm Center receives network logs from organizations and has handlers who help analyze the traffic: https://isc.sans.edu Fireboxes can report data back to WatchGuard (my team!) so we can report on trends, spot new threats and push out updates to protect customers based on the collective data: https://www.secplicity.org/2017/03/29/internet-security-report-q4-2016/
- Follow me on Twitter if you like @teriradichel Security: https://www.secplicity.org/author/teriradichel/ AWS, Programming, Etc. https://websitenotebook.blogspot.com Internet traffic: https://randominternet.blogspot.com Papers: https://www.sans.org/reading-room/whitepapers/casestudies/case-study-critical-controls-prevented-target-breach-35412 https://www.sans.org/reading-room/whitepapers/incident/balancing-security-innovation-event-driven-automation-36837 Packet Capture on AWS ~ Coming soon!