Cloud security best practices, as well as most compliance programs, require that logging be enabled for all in-scope services. However, that simple requirement — “enable logging” — comes with many followup questions. Is CloudTrail enough? How do I turn on logging for all these services? Aren’t logs collected by default? What. even. is. a. log?
In AWS, logging, like most tasks, isn’t as simple as it seems it could be, due to an inconsistent use of defaults, differing destination logging services, and a variety of configuration options, sometimes hidden in layers of submenus and API parameters. …
Last week, I presented a talk at fwd:cloudsec titled “It’s Time to Rethink the Shared Security Responsibility Model.” I argued that the balance of responsibility for securing cloud infrastructure environments has shifted too far in the direction of cloud security and development teams who are overwhelmed with configuration options. This imbalance, I posited, is a driving cause of many of the breaches we see in cloud environments today.
One theme that emerged is that cloud providers can do more to reduce the complexity of their environments and make small changes to their default settings across the services they offer. Integration of security callouts, action items, tooltips, etc. can go a long way to reducing developer mistakes. To help illustrate this point further, I’ve dug through the AWS console and put together a list of changes that I believe could have the most impact, while not requiring significant* investment from AWS. …
Many engineers have found themselves in the unenviable position of being handed the keys to an AWS environment with absolutely no explanation of its contents, documentation, or training. Whether an employee leaves the company, teams are restructured, or your company acquires another, you will need to quickly audit the account and get up to speed on its operation. Even worse, many of these inherited accounts are running production infrastructure that must be kept running during the transition period. Now that you’re responsible for this account, you will also be responsible for keeping it secure.
There is a wealth of documentation, training, guides, and other resources available online to learn about security in AWS cloud environments. But many of those resources assume that you are either building an account from scratch, were intimately involved in building the account from its inception, or can take great liberty in applying destructive changes. In our case, the reality is that you’re likely staring at eight years of accumulated infrastructure with absolutely no idea of what’s running or how to make changes without causing a production outage. …
After upgrading my Lambda functions from Node 10.x to 12.x, I saw the following error in my logs:
Database error: SequelizeConnectionError: 139767860377472:error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol:../deps/openssl/openssl/ssl/statem/statem_lib.c:1929:
Clearly my Lambda function was having trouble negotiating a TLS connection to an RDS instance. Because this is an older MySQL RDS instance (version 5.6), the newer TLS versions (1.1+) are not supported.
Some Googling suggested to add the following CLI flag when starting Node:
However, we don’t have control over the CLI flags in Lambda. Fortunately, Node has an environment variable we can use instead:
Add this as an environment variable and your TLS errors should go away.
Side note: upgrade that endpoint to use TLS 1.2+!
I recently saw a Twitter thread on AWS’s notorious public S3 bucket permissions issue. Some of the replies, especially from AWS folks defending AWS on the issue, got me thinking about whether there are additional improvements that can be made.
While it’s true that AWS has done a lot in the past year to improve S3 bucket security, for some reason we’re still seeing breaches occur with a regular cadence. Something more is needed.
So I fired up my AWS console and started taking some notes. I don’t expect AWS to implement all of these suggestions (I don’t claim to be an expert on the S3 product and am certain to be missing some nuances), but maybe they can reach the right teams who can use them as a starting point for discussion. …
The 2010s have been an incredible decade for cloud computing; the term itself moved from relative obscurity to being the operating model of a good portion of the world’s internet services. Startups, and the capital surrounding them, flooded into tech hot spots as cloud computing offered new ways to develop, deploy, operate, and scale the infrastructure powering these new companies. Existing enterprises, including a majority of the Fortune 1000, rapidly adopted cloud computing, moving a collective trillions of requests per second from their own data centers and into the data centers of Amazon, Microsoft, and Google.
At the beginning of 2010, almost no one could have predicted that the cloud would be adopted as quickly as it had been, let alone entirely new paradigms of compute would be invented — “serverless,” containers, Kubernetes, and more. …