Blog post - Working backwards from log4shell to see why we built lunasec

.gitignore

@@ -21,4 +21,4 @@ outputs/
 !.yarn/sdks
 !.yarn/versions
 
-docs/.yarn/.cache/webpack/client-development-en/
+docs/.yarn/.cache/webpack

docs/blog/2021-12-22-story-lunasec.mdx

@@ -0,0 +1,153 @@
+---
+title: "LunaSec will help protect against Open Source vulnerabilities"
+description: Looking at the latest big attacks to explain why we built the LunaSec Framework.
+slug: lunasec-story
+date: 2021-12-22
+keywords: [open-source, vulnerability, framework, compliance]
+tags: [zero-day, security, data-security, data-breaches, guides]
+authors: [forrest]
+---
+
+<!--
+  ~ Copyright by LunaSec (owned by Refinery Labs, Inc)
+  ~
+  ~ Licensed under the Creative Commons Attribution-ShareAlike 4.0 International
+  ~ (the "License"); you may not use this file except in compliance with the
+  ~ License. You may obtain a copy of the License at
+  ~
+  ~ https://creativecommons.org/licenses/by-sa/4.0/legalcode
+  ~
+  ~ See the License for the specific language governing permissions and
+  ~ limitations under the License.
+  ~
+-->
+
+From the beginning of the log4shell issue, we have been delivering actionable advice and
+[tools](/blog/log4j-zero-day-mitigation-guide#automatically-scanning-your-pack) which can
+automatically find and fix Log4Shell. We were quick to see the seriousness of the vulnerability,
+and helped the community to coalesce into an organized remediation effort. From experience, we
+know that those responding to Log4Shell are in a stressful situation.
+
+It's easy to imagine walking into a meeting
+ and not being able to tell your boss if data has been leaked. Even worse,
+not be able to say for sure if an attack has happened or not.
+While many are having these uncomfortable meetings about security, there has never been a better time
+to lobby for more attention to security and the installation of stronger defences.
+
+We want to make it known that there *are* ways to protect data against attacks like Log4Shell. For the better part of a year,
+we've been building an Open Source framework to make it so these vulnerabilities, even full RCEs like Log4Shell, can't leak the sensitive data
+that attackers are really after. It feels more relevant now than ever.
+
+## Modern attack surface
+In security, we use the word "attack surface" to talk about how much territory we need to defend.
+I think of this like the walls and gates around an ancient city. The bigger
+the town is, the harder and more expensive it becomes to build walls and maintain fortifications.
+
+Modern web applications are bigger and have more functionality than ever before and this surface is becoming unmanageable.
+They use many tools and libraries, all of which could have a potential issue like Log4Shell. Looking forward to the next
+inevitable vulnerability like Log4shell,
+let's look at ways to reduce the size of that attack surface to a much smaller amount of well-audited code.
+
+### Compliance focused tools
+Getting sensitive data **out** of these potentially vulnerable web apps is becoming a popular strategy to help with legal compliance.
+The most popular tools to do this
+are token proxies which convert sensitive fields like a social security number, *435-12-9745*,
+into some identifier token, *token-1234-5678*, which only _refers_ to the sensitive field. While a company using a proxy such as this can quickly
+become compliant given they are no longer storing sensitive data themselves, these tools typically provide next to no actual data security.
+Their focus is mainly just on helping comply with regulations.
+
+In fact, our security researchers have identified actual _vulnerabilities_ in some of these tools which may be trivially exploited
+(more on that and the problems with token proxies in a future post). The short explanation is:
+there are just too many ways to easily get the protected data.
+
+Some tools are better than others, but they all seem to have compromises and some attacks which they don't protect against.
+**None** of them seem to protect data once it reaches the browser.
+We wanted a way to *truly* protect data against *every* [common type of attack](/pages/how-it-works/security/vulns-and-mitigations),
+from browser attacks such as Cross Site Scripting (XSS) to full Remote Code Execution (RCE) like Log4Shell.
+
+### Tools that are ACTUALLY secure
+There's one set of tools with a proven track record for protecting sensitive data on the web, and that's **payment processors**.
+We're talking about tools like Stripe and PayPal that collect your credit card number when you make an online purchase.
+
+They are, in essence, a very small and dedicated web app that
+works alongside your main app. In the browser, your app launches an iFrame containing the payment processor's app. Users see a nice box with a trustworthy logo
+and get to type their credit card information into a safe place. iFrames (in [cross-domain mode](/pages/how-it-works/secure-components)) are
+completely secure when done right because the browser treats them as a totally separate process. This is the strictest security
+tool the browser has. It's like the iFrame is running in a separate tab next to your site, only *appearing* to be a part of it.
+
+After the user is done, the credit card number goes up to the payment processors server. Your server talks to their server,
+and you get the bare minimum information you need to make the sale.
+
+The sensitive data is isolated every step of the way from your system. Even if attackers break in,
+it'll be very difficult to break through to the payment processor and get the credit card number. The attack surface for the payment processor
+is small because it's isolated from your site. Their security teams can audit the changes they make to their small system without worrying about the rest of your app.
+
+### Making that work for any data
+This is a great strategy, and it's worked for decades. It makes sense: credit cards and the laws protecting them have been
+around for quite a while. Now that similar laws and concerns are expanding to more types of data, we need a more generic solution.
+
+Those iFrames loaded by payment processors are designed to be obviously distinct from the app they're in. That's great for payments,
+but ideally a solution that could store *any* data wouldn't be so obvious to the user. We wanted to create an iFrame that visually and functionally disguises
+itself as a part of the surrounding website. Ideally it could be dropped into any form or output that handles sensitive data,
+all while looking like a native part of the web page.
+
+### We call them "Secure Components"
+Dealing with all the DOM information to make the elements look and behave like normal ones took months, but we did it.
+The end result is something that looks and behaves just like a native element, even working well with popular
+component frameworks like Material UI. You can see for yourself in our [Live Demo app](https://app.lunasec.dev/). We've written
+more extensively about [how Secure Components work](/pages/how-it-works/secure-components) in our docs.
+
+```jsx title="A Secure Component in React, replaces a normal <input>"
+<SecureInput name="ssn" token={props.value} onChange={props.onChange} errorHandler={props.handleError} />
+```
+Just like how payment processors give you a "payment ID" instead of a credit card number, the **components return a token** that you
+can store legally and safely in your database, in the same place where you used to put sensitive data. The secure data is handled
+by small and [secure backend](/pages/how-it-works/tokens) that's blindingly fast, very cheap, and scales without limit.
+
+### Secure Functions
+I personally think this is one of the coolest parts of LunaSec.
+
+Processing data serverside is sometimes needed. Sometimes you need to resize a photo, send something to another service,
+capitalize a line of text, send a GDPR report, etc... We want to give users a secure place to do these tasks. We knew there must
+be a way for a server to safely use secret data, even in the event of an RCE.
+
+So now we are building Secure Functions. They look and act like normal functions in your server code, but in fact run in an ephemeral, sandboxed environment.
+Your server can pass a token into the function. The function can exchange that for real data, do what needs to be done, and return anything, just like a normal function would.
+Here's how these will look in Javascript:
+```typescript title="Secure Photo Resize Example"
+import resizeImg from 'resize-image-buffer'
+
+@secureFunction // this decorator transforms the function into a lambda
+async function resizePhoto(token, width, height){
+    const {value} = await lunasecTokenizer.detokenize(token);
+    const resizedImage = await resizeImg(value, width, height);
+    const newResizedToken = lunasecTokenizer.tokenize(resizedImage);
+    return newResizedToken;
+}
+```
+These functions are seamlessly deployed along with your actual application, requiring only a few changes. Because they're deployed to a hardened environment,
+Secure Functions reduce the impact of attacks like an RCE. You still
+need to make sure these parts of your code are secure, but it's much easier to audit something so small compared to auditing
+your entire server.
+
+### Deployment
+We haven't built a pay-as-you-go SASS for LunaSec (at least not yet) because the tool is Open Source and most of our users have wanted to have their own deployments.
+Instead of leaving users on their own in terms of deployment, we wrote [a CLI](/pages/deployment/deploy-with-aws) that uses AWS CDK to deploy
+everything needed to AWS with a single line:
+```shell
+lunasec deploy
+```
+
+Unlike token proxies, LunaSec provides a method for testing your application locally or in CI with
+ [AWS LocalStack](https://github.com/localstack/localstack), a containerized AWS emulator, which will also work in an offline environment. Calling
+```shell
+lunasec start
+```
+brings up everything you need on your development machine, including that local copy of AWS.  Pretty neat! Soon we'll have
+a stubbed-out dev mode that doesn't need any servers running at all.
+
+### Conclusion
+In summary, there *are* ways to protect data against attacks like Log4Shell, and we are working to make them accessible
+and affordable (actually, free) for normal companies and developers. We've also worked hard to make [our docs](/pages/overview/introduction)
+a great resource so please take a look or use the search bar if
+this article has left you curious.  Thanks for reading!

docs/pages/cli/_category_.yml

@@ -0,0 +1,2 @@
+label: CLI
+position: 4

docs/pages/cli/analytics.md

@@ -1,8 +1,8 @@
 ---
 id: "analytics"
-title: "Analytics"
-sidebar_label: "LunaSec CLI Analytics"
-sidebar_position: 1
+title: "CLI Analytics"
+sidebar_label: "Analytics"
+sidebar_position: 5
 ---
 <!--
   ~ Copyright by LunaSec (owned by Refinery Labs, Inc)
@@ -41,4 +41,4 @@ all developers. The metrics that are collected by the CLI look like:
 }
 ```
 
-If you wish to disable these metrics when running the CLI, enable the environment variable: `LUNASEC_DISABLE_CLI_METRICS=true`.
+If you wish to disable these metrics when running the CLI, enable the environment variable: `LUNASEC_DISABLE_CLI_METRICS=true`.

docs/pages/cli/deploy.md

@@ -1,8 +1,8 @@
 ---
 id: "deploy"
 title: "lunasec deploy"
-sidebar_label: "LunaSec Deploy Stack"
-sidebar_position: 1
+sidebar_label: "Deploy"
+sidebar_position: 3
 ---
 <!--
   ~ Copyright by LunaSec (owned by Refinery Labs, Inc)
@@ -17,7 +17,6 @@ sidebar_position: 1
   ~ limitations under the License.
   ~
 -->
-# lunasec deploy
 LunaSec can be deployed to AWS using the LunaSec CLI, available in the `@lunasec/cli` npm package.  More information on installing and using the CLI can be 
 found in the [Getting Started Guide](/pages/getting-started/dedicated-tokenizer/introduction)
 
@@ -36,4 +35,4 @@ module.exports = {
 
 For additional configuration options, please refer to [CLI Configuration](/pages/cli-config/interfaces/DeploymentConfigOptions).
 
-Once the stack is built, the generated AWS Cloudformation template will be present at `~/.lunasec/builds/build_<time of build>`.
+Once the stack is built, the generated AWS Cloudformation template will be present at `~/.lunasec/builds/build_<time of build>`.

docs/pages/cli/installation.md

@@ -0,0 +1,38 @@
+---
+id: "install"
+title: "Installing and Using the CLI"
+sidebar_label: "Installation"
+sidebar_position: 1
+---
+<!--
+  ~ Copyright by LunaSec (owned by Refinery Labs, Inc)
+  ~
+  ~ Licensed under the Creative Commons Attribution-ShareAlike 4.0 International
+  ~ (the "License"); you may not use this file except in compliance with the
+  ~ License. You may obtain a copy of the License at
+  ~
+  ~ https://creativecommons.org/licenses/by-sa/4.0/legalcode
+  ~
+  ~ See the License for the specific language governing permissions and
+  ~ limitations under the License.
+  ~
+-->
+
+The LunaSec CLI makes development, testing, and deployment easier.  It can bring up the services we need to use LunaSec locally.
+
+The CLI is available as an NPM module. Add it to your `package.json` along with the aws cdk packages that it depends on:
+
+`yarn add @lunasec/cli --dev`
+
+or
+
+`npm install @lunasec/cli --save-dev`
+
+Make sure the CLI stays at the same version as the `@lunasec` packages we install in this guide.
+
+:::tip
+You can also install the CLI package globally with `yarn global add @lunasec/cli` to make manual commands easier - it will automatically use the locally installed copy if you are in your app folder. Call `lunasec --version` to try it out.
+:::
+
+### Prerequisites
+Your system must have `docker-compose`, `docker`, and `node >= 14` installed.

docs/pages/cli/resources.md

@@ -1,8 +1,8 @@
 ---
 id: "resources"
-title: "lunasec resources"
-sidebar_label: "LunaSec Stack Resources"
-sidebar_position: 1
+title: "LunaSec Stack Resources"
+sidebar_label: "Resources"
+sidebar_position: 4
 ---
 <!--
   ~ Copyright by LunaSec (owned by Refinery Labs, Inc)
@@ -17,7 +17,6 @@ sidebar_position: 1
   ~ limitations under the License.
   ~
 -->
-# lunasec resources
 
 Print out the resources which have been deployed to the LunaSec stack. 
 
@@ -42,4 +41,4 @@ $ lunasec resources --json
   "grantstableOutput": "lunasec-grantstable-xxx",
   "tokenizersecretOutput": "arn:aws:secretsmanager:us-west-2:000000000000:secret:lunasec-tokenizersecret-xxx"
 }
-```
+```

docs/pages/cli/start.md

@@ -1,8 +1,8 @@
 ---
 id: "start"
 title: "lunasec start"
-sidebar_label: "LunaSec Start Stack"
-sidebar_position: 1
+sidebar_label: "Start"
+sidebar_position: 2
 ---
 <!--
   ~ Copyright by LunaSec (owned by Refinery Labs, Inc)
@@ -17,7 +17,6 @@ sidebar_position: 1
   ~ limitations under the License.
   ~
 -->
-# lunasec start
 
 The `lunasec start --env <environment>` command brings up the LunaSec stack in the provided environment configuration. 
 
@@ -34,4 +33,4 @@ If your system does not require docker to be invoked by the root user (ie. if yo
 [dangerously added your user to the docker group](https://docs.docker.com/engine/install/linux-postinstall/)). You must
 pass `--no-sudo` to the start command in order to have docker-compose run without prepending `sudo`.
 
-To build the LunaSec stack from source, pass `--local-build` from the root of the repository monorepo. 
+To build the LunaSec stack from source, pass `--local-build` from the root of the repository monorepo. 

docs/pages/deployment/_category_.yml

@@ -1,2 +1,2 @@
 label: Deployment
-position: 4
+position: 5

docs/pages/overview/introduction.md

@@ -25,10 +25,10 @@ for the raw data in a process called *Detokenization*.
 
 LunaSec helps to protect yourself from the impact of 0-day exploits by giving you an additional layer of protection 
 against data leaks. It's also the only Open Source Tokenization platform being used in production today, and offers
-more features than even paid alternatives like Very Good Security, HashiCorp Vault, or BlueFin.
+more features than paid alternatives like Very Good Security, HashiCorp Vault, or BlueFin.
 
-With LunaSec you're able to, in minutes, harden your app against 
-[common security problems](/pages/how-it-works/security/introduction/) and make it compliant with privacy regulations (SOC2, PCI-DSS, GDPR, HIPAA, etc).
+With LunaSec you're able to harden your app against 
+[common security problems](/pages/how-it-works/security/introduction/) and become compliant with privacy regulations (SOC2, PCI-DSS, GDPR, HIPAA, etc).
 
 :::info
 
@@ -141,7 +141,7 @@ hoops for "data security" or "compliance", then it's likely that LunaSec can hel
 It's not just for looks.  The other tokenization tools we have audited can make an application compliant with laws and regulations, but they don't actually secure
 data against a number of common attacks. LunaSec *actually* protects your data, even in the browser.
 
-LunaSec is open mainly open source.  Most security tools are hard to use, closed source, or both. We believe that open source is the best choice for production software.
+LunaSec is mainly Open Source.  Most security tools are hard to use, closed source, or both. We believe that open source is the best choice for production software.
 
 LunaSec is simple for normal developers without an advanced understanding of software security or cryptography.
 LunaSec does its best to provide clean and easy APIs, ship with plenty of examples and docs, and will always be open source or source available so that you can debug, understand, or even fix problems yourself.

docs/save-for-later/roadmap.mdx

@@ -0,0 +1,34 @@
+<!--
+  ~ Copyright by LunaSec (owned by Refinery Labs, Inc)
+  ~
+  ~ Licensed under the Creative Commons Attribution-ShareAlike 4.0 International
+  ~ (the "License"); you may not use this file except in compliance with the
+  ~ License. You may obtain a copy of the License at
+  ~
+  ~ https://creativecommons.org/licenses/by-sa/4.0/legalcode
+  ~
+  ~ See the License for the specific language governing permissions and
+  ~ limitations under the License.
+  ~
+-->
+### Future roadmap
+#### Frontend
+At the moment, LunaSec only fully supports React. Our Vue SDK is nearly done, and from there we will be making web-components that should
+work with any framework.
+#### Backend
+NodeJS with either Express or Apollo-Graphql is our currently supported backend. We have an alpha Java SDK that will be finalized soon,
+and we'd also like to add GoLang support. The API for backend service we call "The Tokenizer" is defined in an OpenAPI spec,
+which means you can use the spec file and OpenAPI's generators to generate yourself a simple strongly typed tokenization
+client in almost any language, even if we don't support it officially.
+#### Dependence on AWS
+We are using AWS specific tools pretty heavily. It's not necessary to have an entire app running on AWS,
+just the LunaSec parts. This may still be too much Amazon for some users, and we are not great fans of lock-in, either.
+There is a [massive community](https://github.com/guenter/aws-oss-alternatives) of Open Source projects that aim to be drop
+in replacements for AWS tools. We'd like to give anyone using these tools the same first class support that we give
+to normal AWS users.
+
+### Funding and support
+We're a Y-Combinator backed startup, and we offer paid support to install our tooling or modify it. We ask people to please let us
+know if they need some help or changes! See our founder's post
+[Building an Open Source Business](/blog/how-to-build-an-open-source-business-in-2021-part-1) to learn more about how we pay the bills
+and make an Open Source business work.

docs/sidebars.js

@@ -70,6 +70,16 @@ module.exports = {
         },
       ],
     },
+    {
+      type: 'category',
+      label: 'CLI',
+      items: [
+        {
+          type: 'autogenerated',
+          dirName: 'cli'
+        },
+      ],
+    },
     //   items: [
     //   'getting-started/choose-your-setup',
     //   {