Dawei Jiang

Potential Downsides of Cloud Computing

While we enjoyed many talks on how cloud computing is enabling business, like everything else, there are always some downsides as well. Going to the internet, you can see people’s observation and opinion on cloud downside are primarily centralized with network dependencies, security, compliance, vendor and technology lock-in etc.

This subject deserves a full article, since it is a complex. Today, I am sharing just a portion of the list that deserves leadership attention.

Latency: Cloud requires inevitable travel of data packet from one data center to a few others, depending on how complicate your transaction is. Yes, there are edge computing, content delivery network, local stack (AWS Outpost etc.), and many other ways to reduce the latency. However, a vanilla point to point REST call between two nodes sitting next to each other on the same rack or a few rows apart in the same house will hardly lose to a round trip of cloud. Therefore, study your use case and design, and try not to assume anything. Latency is usually the #1 downside of cloud computing.
You may disagree.

Multiple points of failure: Cloud requires the entire route to function as designed. Network connectives, internet or private links, cloud border and shared network accounts, additional services, their protecting firewalls and many other services come into play. Cloud is no magic. The process of your bytes still happens in a data center nearby. The likelihood of cloud platform failure is no different than traditional ones. A resilient design and a correct implementation can largely mitigate this, but still, when you introduce cloud, you introduce additional integration points. Cloud computing is not a blank check of better resiliency, but a technology stack makes resiliency more possible and easier to implement.
You may disagree.

Shadow IT: You got to love this one. We finally get business compliant with technology department policies and standard, and now they are opening up new space in cloud. Without a strong governance, guardrails and automated detection and prevention, this could quickly spin out of control. Cloud can make business units less dependent on IT, and you may see those old days boxes on the aisle being multiplied easily.
There are many ways to prevent, but it starts from a good governance model.

Loss of control: This is obvious too, and usually be mentioned as one of the cloud drawbacks. Many cloud enthusiasts embrace heavily on “managed services”. While those services are usually a great gain for an organization since it requires no additional workforce skillset, and also provide fast provisioning and ease to use. You are in no business to control them at the granular level you used to be. It is the typical tradeoff you should be aware of.
Some people will say I’d rather not to control it. This is true only when bad thing didn’t happen.

Everything can be expensive: Traditional computing is price bounded. Once a capacity is paid and provision, you can’t over run it. For example, someone’s code is producing errors rather than results, he/she may suffer a VM crash or a downtime, but not a surprising bill. I have seen a missing policy can cause a penny average cloud service incurs thousands of monthly cost. That is 100K times more expensive. A poorly developed Lambda function can be more expensive than a dozen EC2s combined. Please remember, this rule holds true: Errors are definitely more expensive in the cloud. Therefore, cloud computing requires more rigorous software development discipline and enforcement of best practices. Constantly monitoring, alerting, and action taking can all be effective to mitigate surprises. In addition, data move in the cloud could be cost alarming. The bytes going in is free, but every usage could be pricy. Managed peering services among cloud networks can also put a tax on every data that travels. So, please pull a calculator up before you decide a move of “all in”.
Many fascinating stories on cloud cost surprise. Give me a like if you want to hear more.

SLA Creep: What is this? This is service level agreement creep, leading to cost creep. When people come to the cloud, the features and options are abundant and appealing. Some leadership might be under the pressure to “show improvement”. And one wrong way to do it is to promise or up the SLA unnecessarily. For example, changing a daily batch job to real time update. This is potentially breaking the existing logic, or have downstream adverse impact to other programs and services. And in many case, it is also not needed. In another example, changing the daily download amount from previous setting to unlimited. Yes, cloud will allow you to serve your customer without limit, and you will have to pay. I think this category is a highly overlooked one so I put it up for your awareness.
You may disagree.

As a cloud computing leader, this article is a gentle reminder of a few “Don’t do” things. All the potential downsides can be learned, detected, prevented, and mitigated.

Cloud is a beautiful thing when everyone clouds responsibly.

SAMM 2.0 by OWASP

The OWASP^® Foundation released Software Assurance Maturity Model (SAMM) 2.0 last week. This framework targets to build better security posture for all organizations that conduct software development activities, which is a use case of baking security deep into SDLC, regardless of your chosen flavor.

Image credit: https://owaspsamm.org/release-notes-v2/

Using a single GitHub source, the SAMM team now automatically generates the Maturity Model that includes PDF documents, a website, along with the companion toolbox and applications. Model content has been converted to YAML files, improving automation while also allowing tools or other SAMM consumers to automatically use the model.
SAMM 2.0 Press Release

You can see that SAMM is not intend to be a replacement of either your existing SDLC practice, or your current maturity model, such as software capability maturity model (CMM). Instead, SAMM should be interwoven into your existing process. Be part of fabric of your team’s day to day activities.

As a proud individual and capabilities producer (developer and engineer), being chased by project managers on financials and timelines, by testers on defects, and by security professionals on findings and compliances, usually are less motivated parts of our day. Maturity model and process aim to bake those seemingly overhead into routines. Streamline them, standardize them, quantify them, and showcase their benefits the same way development team showcase the features. What you see here is an organic integration of security practices into software assurance lifecycle.

OWASP has a list of exciting projects (https://owasp.org/projects/). The most famous one was OWASP Top 10, see my early post on it. It website has a wealth of information security information and practices you will benefit from.

About the OWASP Foundation: https://owasp.org

About OWASP SAMM: https://owasp.org/www-project-samm

NIST Special Publications 800 Series – Major Readings

National Institute of Standard and Technology (NIST) Special Publication (SP) 800 series are familiar topics to people who work in federal workspace. 800 series presents information of interest to the computer security community and comprised of guidelines, recommendations, technical specifications, and annual reports of NIST’s cybersecurity activities. NIST develops SP 800-series publications in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA).

The challenge is there are close to 200 publications. How does each one fit with our work? Some publications are highly specific to an domain, such as 800-187: Guideline to LTE security; 800-167: Guideline to Application Whitelisting. You can pretty sure those are your interests related to your specific roles in your organization.

Meanwhile, I summarize about 15 publications for general awareness. In this list, you will find foundation publications, global awareness subjects, and emerging concepts and ideas.

NIST articles is not like your favorite novels. Not only it could be boring, but also hard to memorize. But imagine them to be cook books and recipes if you want to be a serious cook. The documented information are guidelines that derives your organization’s normal procedures you already use each day.

I created two illustrations to highlight why I consider some publications worth your time of a look up. This is the official site when you access the information: https://csrc.nist.gov/publications/sp800

Log4j vulnerability: What and how in plain language

All organizations and their technology department woke up last week (if not earlier) with the earthquake news about Log4j vulnerability. This is labeled as the worst known security vulnerability with a maximum CVSS score of 10, due to the nature of how wide spread it is and how easy the exploit can happen.

In this posting, I quickly drew a simple diagram to illustrate the scenario on how easy you can get attacked. Please feel free to create and distribute your version for public awareness.

Log4j is a common logging framework many Java application uses. JNDI allows the connection to external directory services and binds a remote object to a name. This particular vulnerability was introduced since 2013.

There are so many videos and writings about Log4j. I want to point you to official NIST website: https://nvd.nist.gov/vuln/detail/CVE-2021-44228

CVE-2021-44228 is the official entry of description, reference of solutions and advisories. You should follow through this record and closely work with your internal teams and vendors to apply patch (scan, identify, and replace) and other compensating controls to deter and prevent the potential threats.

Some recommendations for the what you can do now:

Upgrade and replace log4j library.
If upgrade is not possible (mostly due to legacy decencies), disable JNDI look up feature.
Sanitize input. The attack is an injection problem to start, like most SQL injection in nature.
Leverage WAF, and block suspicious ingress traffic.
Monitor egress to prevent remote invocation.
Last but not least, don’t forget inside your network.

I will follow up with a few other posts on this subject soon.