The cloud is a constantly evolving, and oftentimes hostile, environment for security teams. Even the most well-designed security programs can fall victim to new attack vectors, complex multi-stage offensive activity, or even simple missed misconfigurations.
Like disaster recovery plans, cloud security response processes are useless if they are not reviewed, practiced, and updated on a regular basis. In an ideal world, this is done quarterly as a cross-team effort among the security, compliance, infrastructure, and operations teams.
Despite all best efforts, new situations may arise at any time that have not been practiced previously. It’s important for security teams to…
There has been a lot of dialogue concerning “supply chain attacks” recently, especially after the SolarWinds incident thrust it to the forefront. When “supply chains” are discussed, most analysis tends to focus on that of the software supply chain — build systems, dependencies, libraries, and other components of the software package that can lead to unintended code execution.
In fact, this is what is believed to have been part of what was at play for SolarWinds; an unexpected piece of code was added to the software early enough in the build process that the final binary was still signed by…
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…
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…
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…
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…
Founder of @CloudSploit , acquired by @AquaSecTeam . Former Infra / Security / Manager @Adobe , @Aviary & @Mozilla intern, @RITtigers grad, @NYC resident