In part two of the Cloud Network Security blog series, we will discuss two methods of securing your network within Amazon Web Services: security groups and network access control lists (NACLs). Both resource types act as a virtual firewall to protect your network, and they have some similarities. For example, security groups and NACLs both use sets of inbound and outbound rules to control traffic to and from resources in a VPC.
Network security is critical to operating in the cloud. There are many different ways you can secure your network, but the best approach is to layer multiple methods. The more layers implemented in your security, the harder it is for malicious actors to access your network.
Cloud misconfiguration is the number one cause of data breaches involving public cloud services such as those offered by Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform. According to Neil MacDonald at Gartner, “nearly all successful attacks on cloud services are the result of customer misconfiguration, mismanagement and mistakes.”
We love clouds like Amazon Web Services (AWS) and Microsoft Azure for more reasons than we can count. Because the cloud is 100% software, we can program it to respond to our application requirements automatically. Developers can innovate really fast, spinning resources up and down on demand, and we only pay for what we use.
Most enterprises are already using public cloud computing services at scale or are planning to adopt the cloud soon. As an executive, chances are you’re paying attention to the Capital One data breach and wondering how this event should impact your decision-making.
UPDATE: August 26, 2019Since posting this, AWS has made some public statements regarding the breach that shed some light on what likely happened. From their response to Senator Ron Wyden, AWS stated:"As Capital One outlined in their public announcement, the attack occurred due to a misconfiguration error at the application layer of a firewall installed by Capital One, exacerbated by permissions set by Capital One that were likely broader than intended. After gaining access through the misconfigured firewall and having broader permission to access resources, we believe a SSRF attack was used (which is one of several ways an attacker could have potentially gotten access to data once they got in through the misconfigured firewall." "As discussed above, SSRF was not the primary factor in the...
For twelve years I’ve held executive management positions at companies making significant use of the cloud. Now I have the privilege of helping lead Fugue, a leading provider of cloud security and compliance solutions. Along the way I’ve found that senior executives—both at technology companies and outside the tech industry—sometimes struggle to understand the security implications of moving to the cloud. It’s common for executives to simply make blanket declarations that the cloud will never be secure enough for them (untrue), or alternatively to hold the belief that the cloud service providers like Amazon, Microsoft and Google take care of all the security issues for you (also untrue).
If you consider how rapidly organizations are increasing their cloud footprint, ensuring compliance with the different compliance standards can get challenging very quickly. Here at Fugue, we aim to make compliance easy, so in this blog, we are going to break down the complexities associated with SOC 2 compliance.
We’re thrilled that DeveloperWeek NYC has awarded Fugue a DevProject Award for the work our amazing engineering and product teams delivered to bring our Software as a Service (SaaS) solution for cloud security and compliance to market.
In the last part of this series, we're going to look at the final stages of the software development life cycle (SDLC)—deployment and operations. As a reminder, in parts one and two, we discussed the overall concept of shifting left for security and compliance, and laid out some best practices for how to do so during the development and testing phases of the SDLC. In this post, we'll cover how using policy as code and baselines allows you to leverage all the work done in the earlier phases to prevent deployment of misconfigurations and ensure that your deployed infrastructure remains functional and compliant over time.