On May 8, I attended the AWS Summit in London. The event featured global announcements, networking, multiple breakout presentations on the latest cloud technology solutions, access to AWS experts and architects, hands-on learning, and an even bigger solution expo. Whether delegates were new to the cloud, or an experienced user they had a chance to learn something new. One thing I didn’t expect to hear at the show was: “I utilize AWS, so I don’t have to worry about security, right?”
IT security must be a key design element at the beginning of every project, waiting until production systems are to go online is too late. Development and testing systems are commonly placed online to enable DevOps, exposing the underlying systems. One must only look to the recent Jenkins Remote Code Execution to see that it is not only web applications that expose us to attackers.
Secondly, consider how security is assessed during the development and build of applications and their supporting infrastructure. Ensuring good risk assessment using tools and services should permeate the entire pipeline.
AWS shared responsibility model
Who is responsible for securing AWS? From the very beginning, AWS declared a diminished security burden for the businesses utilizing the cloud. The shared responsibility model clearly articulates that AWS is responsible for protecting the underlying infrastructure that runs the services in the AWS cloud. When we see that AWS provides a level of PCI compliance or other security compliance it is this that it refers to, not the systems that customers deploy.
AWS and other cloud providers deliver a very secure starting point, a closed box that customers can very easily configure their way to an insecure configuration, exposing themselves.
Customer responsibility will be determined by the AWS cloud services that a customer selects. This determines the amount of configuration work the customer must perform as part of their security responsibilities but—to put it simply—the customer is responsible for the security of their assets within the cloud.
Metamorphosis of the cyber threat landscape – attackers still targeting the application layer
Web-based applications, unpatched operating systems and application packages, as well as poorly configured cloud services are prime targets for attackers. According to the newly released Verizon 2019 Data Breach Investigations Report, web applications are the leading top hacking vectors in breaches (over 60 percent).
Understanding your security responsibilities in cloud environments and utilizing security tools that empower you to continuously monitor and manage secure configurations and patching is essential to asset protection from application-layer attacks.
With application workloads in the cloud, businesses need to be mindful of the risks and have visibility in their cloud stack for all systems, especially those that are exposed or hold sensitive data.
A breach is equally a business problem as an IT one, perhaps more so. A compromised web application can lead to several different scenarios including compromised servers through a remote code execution leading to further compromise, don’t assume that web application breaches are contained within the application.
Consequences of a cybersecurity breach
Breaches have a massive impact on goodwill and loyalty for the company’s customer base, particularly if the breach involved sensitive data being stolen. Confidential information regarding the company or employees could also be leaked, the web application could become unavailable, and with any of these potential storylines, a company is likely to have to undertake post-breach activities and bear significant costs in investigative, remediation, legal, PR and regulatory efforts.
This requires the company’s leadership to take ownership of understanding the risk and attack surface of their workloads and business-critical web applications, the shared security responsibility and ensure that they identify high-risk areas to address—before the cyber attackers get there first.