We can use a Docker container to run Node.js and install npm packages.

What are Docker containers and why should we use them?

Docker is a software technology that creates a container that runs on our computer. A container is like running a mini computer within ours and restricts access to our files.

The problem with running Node.js on our computer is the growth of malicious npm packages. There are some malicious actors that purposely put malware in npm packages. They create packages with similar names (called typosquatting) hoping we will install the incorrect version so they can deliver the malware.

These types of npm attacks have been growing significantly and will continue being an issue in 2022 and future years.

What if we installed a malicious npm package and we can limit the extent of the damage? That is where containers can help.

Suppose we installed an npm package that deployed ransomware. All our files would become a victim to the ransomware attack if we were running Node.js on our computer.

Suppose we installed it inside a container. A properly configured container will limit access to the files added to the container. In theory, only those specific files will be compromised and our personal files should be protected. We can stop the container, delete the container image, purge all files associated with the container, and run an antivirus scan just to be safe. Given we commit our code to a software repository, we probably only lost a little bit of our code.

Using a Docker container to run Node.js is like putting our code in quarantine so that an infection does not put a strain on the whole computer.

How do I set up Node.js and npm on my machine?

Start by installing Docker Desktop on our development machine. We will want to create a Docker account also to take advantage Docker scan feature that we will discuss later.

After we install it, go to the settings.

Enable “Docker Compose V2” in the “General” section.

General settings.

Set the desired resource load in the “Resources Advanced” section.

Advanced Resources settings.

Ensure software updates are enabled.

Software Updates settings.

Go to our code folder. Create a file called docker-compose.yml in the top-level directory (or in every folder that we want a customized container).

version: "3"
services:
  dev:
    image: "node:14.18.1-buster-slim"
    user: "node"
    working_dir: /home/node/dev
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./:/home/node/dev

The Docker Compose file creates and runs a Docker container without to build it.

The image: property defines the node container. The example uses an official Node.js container image. The version was selected based on the recommendation from the Docker scan.

The working_dir: property defines the home directory as /home/node/dev. (When we start the container it will show dev as the current folder.)

The volumes: property allows running Docker within container and puts all the files where the docker-compose.yml exists, and mounts them to the /home/node/dev directory within the container. (We can delete the first line if we do not need Docker running within the container.)

Using another image like one from Circle (e.g., circleci/node:14-bullseye) provides git and other common Linux utilities.

version: "3"
services:
  node:
    image: "circleci/node:14-bullseye"
    working_dir: /home/node/dev
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./:/home/node/dev

In our computer’s terminal, run the following command to start the container.

docker compose run --rm dev bash
# Or the following if Docker Compose v2 was not checked above
docker-compose run --rm dev bash

We will now see a prompt like node@502104098e72:~/code$ in the terminal. This means our terminal is now inside the Docker container running node.

Type the ls command to see our files. We should see our the files within the directory.

Open Docker Desktop and we will see our container running.

A container is running.

We can now run npm i -g some_package_name and npm ci within the container.

(If we have Node installed on our machine, we can try installing a different global npm package in our container. We open a new terminal window, try running the global npm package and we should get an error because it is only installed in our container.)

In the container’s terminal, type the exit command. Go to Docker Desktop and we should no longer see the container.

No container is running.

The --rm flag in the docker compose run commands tells Docker to delete the container after it terminates. This way we can keep our machine cleaner.

Keeping Docker up to date and clean

We should apply the Docker software updates when they become available.

After we apply the updates, we should scan our container for vulnerabilities with a Docker scan.

We need to accept the license to get started with Docker scan.

docker scan --accept-license --version

We can scan our Node.js container with the following command.

docker scan node

The scan output will recommend which container image to use. We will update the image: property within the docker-compose.yml file to have the recommend image.

Every so often we should clean up the images.

Cleaning up images.

And remove old volumes.

Removing volumes.

Conclusion

Using Docker containers is one way to protect our computers from malicious npm packages and Node.js vulnerabilities because code execution and runtimes are isolated to the container.

Want to Connect?

Miguel is a Principal Engineer and the author of the “Serverless Security” book. He has worked on multiple serverless projects as a developer and security engineer, contributed to open-source serverless projects, and worked on large military systems in various engineering roles.

Originally published on Medium

Photo by Tom Winckels on Unsplash

It was about ten years ago, and the director of engineering took a chance on me. She assigned me to work on a mega-multi-million dollar program. This program also had several million dollars in incentives if the project achieved milestones ahead of schedule. This project was a big deal, and I was assigned to be the first team member of the networking engineering team.

The team only had the manager and the technical lead. The team needed to build a large multi-site and resilient network for this important customer. I had never worked with these two leads before. Yet, the technical lead told me I would be responsible for designing and building the voice over IP (VOIP) phone system.

I had never built a VOIP phone system before. I was still relatively new to networking engineering too. Now another person was taking a chance on me.

Usually, I would have been too afraid and chickened out. This was a big responsibility with a lot at stake.

I did not realize at first that this customer relied more on the phone systems than on the computer systems to do their work. The phone system had to be more resilient and better designed than the computer systems. (Of course, the network had to be just as resilient to support the VOIP phone system too.)

To top it off, I would be the only person designing and building the phone system. In contrast, the manager would bring in several people to work on the network.

How could such an important system be assigned to someone who had never even built one?

Rather than chicken out, I went against my nature and took on the challenge.

I spent two months reading the customer requirements and the VOIP system technical manuals. I made sure I read every page of those manuals and the customer requirement documents. I ensured every requirement could trace back to the VOIP functionality presented in the manuals.

When it came time to meet with the technical lead to discuss design, I answered most of the questions. I took action to research those I could not answer.

The technical lead had built phone systems with bare-metal systems. Learning about his experience over the past several decades was eye-opening. A lot went into powering and supporting a “simple” phone call.

I typically would have followed the same patterns and the guidance from my technical lead. Why not? He had several decades of experience when I did not. Yet, it did not play out that way.

I had several meetings with the sales engineers from the company from which we would be buying the VOIP technology. Those people were very knowledgeable.

I had remembered reading about virtualization technology, and I inquired about it. They assured me this new technology would achieve the same results as the bare metal solutions. I took a note and researched it some more.

The more I read about it, the more I was impressed. This seemed like the future. I asked some fellow network engineers about this. They had not used this yet in any previous system. Would I dare take the plunge and propose a new technique for this high-value customer?

I eventually proposed the virtualization design to the technical lead. He was pretty upset and wary. This was new. This was different. This seemed very risky.

I remember he told me something like, “We will try it and present it to the project’s technical director. If he doesn’t like it, it’ll be on you.”

This seemed acceptable. I agreed.

The technical lead presented the design to the technical director. He had some questions and seemed pensive. He asked some questions on design items I had not considered. After all, he did not become a technical director without thoroughly assessing systems for resiliency.

I took note of the technical director’s concerns.

What happened next shook me and stuck with me.

My technical lead turned to me and said, “I knew I never should have listened to your virtualization idea.”

I felt I messed up royally.

As I researched the answers to the technical director’s questions, I realized that the questions were good. He was not questioning the design but making sure the design was resilient. There were no negative comments from the director — only from my lead. Maybe the director could accept the new virtualization design.

I found the answers and submitted them to my lead, who presented the findings to the technical director. The technical director liked the explanations and approved the design.

When it came to procuring hardware six months later, we did not have to procure separate hardware for the VOIP system. We could simply use the servers that we already needed to buy for the data center we were building. Furthermore, we could simplify the network design too.

By adopting virtualization for the VOIP systems, we were able to save about $1 million in hardware costs.

(As an added bonus: the network engineers and the technical lead had a much easier time installing the VOIP system at all the customer sites. It would have been nice to have been there too, but I could not travel for personal reasons.)

Conclusion

Preparation was essential to achieve this good outcome. I spent a lot of time working on my assignment. With the knowledge I had acquired, I could spot an opportunity that I would have missed otherwise. I respected my technical lead’s and the technical director’s concerns, and made sure I answered any questions as best as I could. Having the preparation in place, I was able to take a calculated risk that paid off.

Don’t be afraid to take a risk, especially when you’ve done your homework.

Before you go

About the author

Originally published on Medium

Photo by Eunice Lituañas on Unsplash

Why is the OWASP Serverless Top 10 important?

In this video, I discussed the reasons why the OWASP Serverless Top 10 cybersecurity risks for a serverless application are important to consider.

Injection attacks

In this video, I discussed what is the injection attack.

Broken authorization

In this video, I discussed what is broken authentication and authorization.

Sensitive data exposure

In this video, I discussed the sensitive data exposure risk.

XML external entities

In this video, I discussed the XML external entities risk.

Broken access control

In this video, I discussed the broken access control risk.

Security misconfiguration

In this video, I discussed the security misconfiguration risk.

Cross-site script attacks

In this video, I discussed the cross-site scripting (XSS).

Insecure deserialization

In this video, I discussed the insecure deserialization risk.

Vulnerable components

In this video, I discussed the risk of using components with known vulnerabilities.

Logging and monitoring

In this video, I discussed the insufficient logging and monitoring risk.

Before you go

About the author

I am in a cybersecurity writing group with Nihad, where he shared he had published his 4th book; this was back in 2019. I was impressed by his accomplishment, and it made me wonder, "Maybe I could write a book too."

I read about the Apress author program and tucked it away in my memory.

A few months later, I started wondering why information on serverless security was so disparate. It was almost the summer of 2019, and I did not see one book published on serverless security.

I realized there was a need to be filled. Maybe this was my opportunity to write my first traditionally published book.

The rest is history, and Serverless Security was published on October 6, 2020.

I wrote this post for two reasons.

1. Thank Nihad for his inspiration and Apress for making it become a reality.

2. To share that an idea and life goal can be achieved, and by sharing our accomplishments, we can inspire others to achieve their goals and realize their ideas and dreams.

Go ideate, execute and make your ideas a reality.

Happy Monday!

Before you go

About the author

Photo by Adi Goldstein on Unsplash

Have you heard, “If you build it, I will break it?”

This is a skill I developed over my career to build better systems. It is a skill that took me a while to learn I had.

Shortly before I graduated from college, I decided to leave the material science industry because I had a tendency to break stuff. When working with toxic substances, this can be hazardous. As a result, I changed to the systems engineering field.

It turned out I had a knack for breaking stuff there too. For a long while, I avoided working on things I could break. Yet, I found I wasn’t growing as much as my peers. So I decided I needed to do some hands-on work.

As it turns out, I was breaking stuff, and people were getting mad. They had to fix deficiencies and errors I discovered. A time came people started expecting me to fix what I broke. That was a pivotal moment in my career.

I had to learn how to fix things, and I wasn’t trained as an engineer. My undergrad was in material science. I started learning how to fix things and became more knowledgeable about the technology. I eventually learned how to find defects, flaws, and deficiencies in designs.

I turned what I thought was a flaw into a skill. I could help build more reliable systems by “breaking them.” Penetration testers do this type of work. They look for vulnerabilities and ways to break “in.” I had a knack for finding ways to break “down” systems. If I can learn why a system could falter, I can help prevent it.

My recommendation for your systems: Plan to break your system before it breaks on you.

Before you go

About the author

Originally published on Medium

Photo by Marc Rafanell López on Unsplash

Polls on LinkedIn and Twitter

I wanted to know what my social networks thought about this question. I already had my own opinion and experience, but did others share my view?

I structured the LinkedIn and Twitter polls to not only get a "yes" or "no" answer. There were designed to assess whether being phished affected responses. The first two options for each "yes" and "no" answer were aimed to figure out which participants might have been phished themselves. The second options for each "yes" and "no" answer were to see who has not been phished.

I received very few responses, but the results were still illuminating.

LinkedIn poll results

Twitter poll results

Combined poll results

Poll results

Surprisingly, many respondents believe security engineers cannot be vulnerable to phishing. This belief highlights security engineers have become well respected. This respect may be due to the increased awareness of the need for cybersecurity. I see a concern here: security engineers could become overconfident and make more mistakes, thus becoming future targets. Although the majority thought security engineers could not get phished, no one ruled out the possibility.

Of the remainder who answered "yes," the majority were not phished. I was supposing that many of the "yes" answers would come from individuals who themselves were phished. Surprisingly that was not the case. It seems those who answered "yes" are being realistic that anyone could get phished even though they were not.

Conclusion

The number of responses were small and cannot be representative of everyone. It was surprising to learn that the majority of the respondents thought a security engineer could not be phished, but they did not rule out the possibility.

Personally, I think anyone is vulnerable to phishing, and that includes security engineers, security directors and chief information security officers.

Slow down and think. Whoever is asking for an urgent response can wait. If it was so critical, that person would have called many times and gotten the phone number from an acquaintance if needed.

Stay secure and alert, Miguel

Before you go

About the author

Originally published on Secjuice

Photo by Rachel Hisko on Unsplash

I was surprised. I did not think viruses were technically possible on iOS devices.

I agreed to help.

I asked, "What did you notice that makes you think you have a virus?"

This person replied, "I started seeing pop-ups telling me I was hacked."

I pondered the response. "What app were you using?"

"I was using the Google app."

"Do you remember what you were doing there?"

"I searched for a former president's name and clicked the search result. It didn't take me to a website. Instead, it took me back to the Google search page."

I pondered the response. How could searching a president's name get oneself hacked?

"Look!" this person said. "The pop-up is there."

I looked at the phone and saw it was a calendar reminder notification. Interesting!

I opened the calendar app and saw calendar entries with scary titles and links to potential phishing sites.

Hacking through someone's calendar?! These malicious actors are incredibly clever.

I removed the subscribed calendar account and asked this person to clear the cache from all the web browsing apps.

I used my own device to find out how this was possible. I found an article that explains it. (See the link below). Turns out this is a relatively new attack vector.

https://macsecurity.net/view/333-iphone-calendar-events-spam

I asked, "Do you remember clicking some alert when you were browsing the web?"

"Well, yes. I got an alert. It had a button that said, 'Okay, got it." So, I clicked it. I don't remember what it said."

I suppose this person clicked a malicious pop-up alert that subscribed the calendar to a malicious shared calendar.

Fortunately, this person did not click on any of the calendar notifications. The bad news: this event reminded me that cyber defenders could continue to be behind the cyber attackers. I would not have considered an attack via a calendar app.

Before you go

About the author

Originally posted on Patreon

Photo by Estée Janssens on Unsplash

What is a serverless website?

A serverless website is a website that runs without a server. It may seem impossible because every website needs a server. Object storage services (e.g., S3) allow serving HTML files and their supporting files. The browser just needs the HTML files, and it will fetch all the related files based on the HTML code. Think of simple HTML websites with dynamic code (e.g., PHP or Python).

What do I need to create a serverless website?

You will need static web page files (i.e., HTML, JavaScript, CSS, and image files). If the website correctly displays in a browser by double-clicking the file on your computer, it will work as a serverless website.

You will need an AWS account. You will need a credit card to sign up for AWS. AWS accounts are free, but you pay for any services that you use. Fortunately, serverless websites are very cheap. I host three serverless websites for $0.05 per month.

You will probably want a custom domain to have a readable website address. You can buy one on AWS or use a domain name provider. This post assumes you already have a custom domain.

You will need the Serverless Framework to follow along with the rest of this post. Use the Serverless docs to install and set up the Serverless Framework.

Setting up the domain with Route 53

Route 53 is the AWS service that deals with domain names and DNS records. We will need to set up a Route 53 hosted zone to create the domain name records required to route the custom domain name to the serverless website.

We will use a Serverless Framework plugin to create the hosted zone: the serverless-hosted-zone plugin.

To install it:

cd to-my-serverless-project
npm install --save-dev serverless-hosted-zone

To add it to the serverless.yml configuration file:

plugins:
  # add to the previous entries
  - serverless-hosted-zone

custom:
  # add to the previous entries
  # see the documentation for all the options
  hostedZone:
    name: customdomain.com. # Note the trailing dot

To create the hosted zone:

sls create-zone

Now we have a hosted zone in our AWS account for the customdomain.com domain name.

Setting up a certificate

The AWS Certificate Manager service allows us to create a free certificate. That way, we can use HTTPS for our serverless website (and make Google and our website visitors feel happy and safe).

We will use a Serverless Framework plugin to create the hosted zone: the serverless-certificate-creator plugin.

To install it:

npm i --save-dev serverless-certificate-creator

To add it to the serverless.yml configuration file:

plugins:
  # add to the previous entries
  - serverless-certificate-creator

custom:
  # add to the previous entries
  # see the documentation for all the options
  customCertificate:
    certificateName: customdomain.com
    idempotencyToken: customdomaincom
    hostedZoneNames: customdomain.com. # Note the trailing dot

To create the certificate:

sls create-cert

The plugin creates the certificate and registers the DNS records in the hosted zone.

Creating the serverless website hosting

We will assume you already have the static HTML files you want to use for your serverless website. We will create an S3 bucket and a CloudFront distribution for our website. S3 is the object storage where we upload and serve our website files. CloudFront is a Content Delivery Network (CDN) to efficiently serve the website files. We will associate the certificate to the CloudFront distribution.

We will use a Serverless Framework plugin to create the S3 bucket and CloudFront distribution: the fullstack-serverless plugin.

To install it:

npm install -g serverless

To add it to the serverless.yml configuration file:

plugins:
  # add to the previous entries
  - fullstack-serverless

custom:
  # add to the previous entries
  # see the documentation for all the options
  fullstack:
    domain: customdomain.com
    certificate: arn:aws:acm:us-east-1: # use the actual ARN
    bucketName: customdomain.com # the desired bucket name
    distributionFolder: my-website-files-dir # assumes it is in the  same directory
    indexDocument: index.html
    errorDocument: error.html
    singlePageApp: true
    compressWebContent: true

To deploy your static HTML website:

# no-generate-client option because only using static files
# omit if you are using a reactive framework (e.g., React, Vue, Nuxt, Next)
serverless client deploy --no-generate-client

Updating the domain name pointer

If you bought your domain name within AWS Route 53, there is nothing left to do. AWS created automatically created the customdomain.com. hosted zone for you and the plugin checked for it.

If you bought it somewhere else, you should update the DNS records with that provider and point it to the CloudFront distribution.

You may have noticed the plugin output a DNS name (e.g., abc1d2efghij4.cloudfront.net.), or you can go to the AWS console to get the CloudFront distribution DNS name. Go to your DNS provider and create an ALIAS record pointing to abc1d2efghij4.cloudfront.net. so anyone that visits https://customdomain.com will see your new serverless website.

Conclusion

With three Serverless Framework plugins, we created a serverless website to serve static HTML files. We can use this same approach to serve a Single Page Application designed with a reactive framework (e.g., React or Vue). We should point our domain name to our new serverless website if we purchased the domain outside of AWS.

Before you go

About the author

Originally published on dev.to

Photo by KOBU Agency on Unsplash

Introducing Helium and the People’s Network

Helium created a new wireless network that uses Long Range WAN (LoRaWAN) technology—they call it LongFi. This technology builds the People’s Network, where anyone can contribute to the infrastructure and use it for data transfer. Anyone can buy a Helium hotspot from $500-$600 with taxes and shipping. (This is roughly one of the United Status stimulus checks sent out for one person.) Once you set up your hotspot, connect it to your home network and join the Helium network, you can start earning the HNT cryptocurrency.

Bobcat miner for Helium

Earnings potential

The Helium miners build the network and are rewarded with HNT for various activities. Imagine investing $600 in a miner, and it earns $1,600 in the first month. You have recovered your start-up costs and gained $1,000 in gains! That’s amazing. See the example hotspot below that shows proof it is possible.

Furthermore, the price of HNT may increase in value when the HNT halving happens in August 2021. That $1,000 in gains could grow.

This hotspot earned almost 160 HNT. (An HNT is about $10 at the time of this writing.)

Helping yourself and/or others

Participating in the People’s Network with a miner can provide you with a passive income source. But what if you could use it to benefit others? Imaging buying a miner for a cash-strapped family, that college student who is unable to pay tuition and board or your favorite non-profit, and sharing your HNT income. Not only would you be helping build a new network, but you are now helping those in need.

Maximizing the earnings potential

There is no guarantee that each miner will earn the same amount of HNT. Many factors contribute to earnings (e.g., location, antenna gain, elevation, etc.). You will want to tune your hotspot to maximize the earnings potential.

Risks

There are potential risks. Here are some:

• Introducing a new device to your home network could be a cybersecurity threat.
• You may have added costs (e.g., upgrading your home Internet speed to support this new device and increased electricity usage).
• Falling victim to scams (e.g., attempting to buy a miner from a fake miner web sites).
• Losing access to your Helium wallet by losing the secret key. -Having your Helium wallet stolen.

There are many risks when it comes to new technologies and cryptocurrency in general.

Rewards

These are some rewards I can think of:

• Earn passive income for you, someone else in need, or a non-profit.
• Participate in a new technology revolution.
• Use the network to send Internet of Things (IoT) data at a low rate.
• Build a network that enables the creation of new ideas and inventions.
• Join the world of cryptocurrency.

There are many other rewards that I have not listed.

Why did I decide to participate?

I accidentally stumbled onto Helium while I was researching and learning about cryptocurrencies. I loved the concept from the start. I came from a networking background and have dabbled in IoT. The thought of building a new type of network that was decentralized, long-range, durable, and scalable was impressive on its own. But knowing that anyone who helps build it gets incentivized made this project lovable.

It took me a couple weeks before I decided the spend over $500 to buy my first hotspot. “Was it worth the risk?” was a question I needed to answer. After researching the earnings potential from other hotspots, better understanding the technology, and determining the return on investment (ROI), I was sold. It would take me three months to get my miner, and it could take up to three months to get a return on my investment. There are few opportunities when you can recoup your initial investment in 6 months or less. And being part of a new revolution sealed the deal for me.

Later, when I realized I could support those in need and my favorite non-profits, I knew I was onto something big.

I hope you found this post beneficial. None of the text in this post is investment advice. Cryptocurrencies and new movements may crash and burn overnight. Weigh the risk-reward ratio for yourself rather than trusting me.

Before you go

About the author

Originally published on Medium

Photo by Kyle Hinkson on Unsplash

That is a question I had when I first learned about them.

Learning is important.

I was impressed with how well designed were JWT, OIDC, SAML, and modern Identity Provider (IdP) solutions. The quality of the design I read about in the Request for Comments (RFCs) was impressive. Yet even after reading the RFCs and watching tutorials, something was still nagging at me.

Test assumptions and concerns.

One day I decided to log into one web application and copied the JWT using the Chrome developer tools.

I went to another web application and opened the Chrome developer tools. I added the other site's JWT token and refreshed the page.

A surprise outcome.

I logged in!

I had an active login, but there were multiple errors and missing data within the different views.

After some investigation, I realized the APIs validated the JWTs, but the web application client did not.

What is cybersecurity?

Even well-designed solutions and technologies require secure implementation.

When something is nagging at us, or we suspect a potential flaw, we should take the time to investigate and test it.

Before you go

About the author

Originally published on Patreon

Photo by ZSun Fu on Unsplash

Replacing a doorknob.

I needed to replace a doorknob. We had been living in our home with the original locks. I was concerned the previous owner may have kept a copy of the key and might want to enter our premises uninvited.

I performed a risk assessment.

I bought a new doorknob manufactured from a reputable brand, and that looked pretty. I trusted this brand to provide more than adequate protection. I felt that paying extra was worth the extra security.

I identified the mitigation.

It was time to improve my home's security. I removed the old doorknob and installed the new one.

I implemented the mitigation.

I felt pretty good until...

My gut performed an unconscious risk assessment. I started to feel uneasy. I began to think, "Did I do it correctly?"

My conscious mind realized I needed to update my risk assessment.

You might think this is a ridiculous question. Of course, a new doorknob would prevent the previous owner from entering uninvited. This might be the logical conclusion, so why bother with another risk assessment?

I decided to stand outside, close the door, and kick the door. To my surprise, the door opened wide. Huh?!

I installed the doorknob backward!!

The mitigation was unsatisfactory.

I fixed the doorknob, closed the door, and kicked hard (several times). The door remained closed.

I addressed the findings from both the old and new risk assessments.

So what is Cybersecurity?

Think about what could go wrong, find ways to address them, make the changes, and repeat the process.

When you implement a fix, make sure to test that it works too.

Before you go

About the author

Originally published on Patreon

Photo by Dima Pechurin on Unsplash

Over ten years ago I enrolled into an MBA where I learned how to write to high-level business people. I have refining what I learned since then. I am sharing what I have learned to save you the cost of an MBA and over a decade of practice.

Leaders are busy. Get to the point.

Bosses, supervisors, directors, and CXOs are busy with many responsibilities. We should aim to take up less of their time and give them actionable information to make decisions faster.

Leaders should read your message and get all the necessary information in less than a paragraph. That is difficult to do after. With practice, it becomes easier.

Leaders should be able to respond quickly too. Your questions to them should allow them to reply with "yes," "no," "why?" or a concise sentence. A faster response will enable them to move onto the next item on their busy day.

Two requests to a leader.

We will review two requests from an engineer to a CEO. The engineer was tasked to investigate a "thing" and find the best choice to get it done. The engineer will present the best options so the CEO can make the final decision.

Here are two examples: a not-so-good one and a better one.

A not-so-good example.

Dear CEO,

I have spent the past few weeks researching this "thing." I have done multiple assessments, spoken with many vendors, and conducted various tests. I have narrowed down the final choices for the "thing."

The first choice is not as good because it requires "widget X" and will take several months to implement. But it will save us 5% per month after two years. Read the attached document for the rest of the details.

The second choice is better. It does not require any widgets, but it will still take several weeks to implement. It will only save us 4% per month after one year. Read the attached document for the rest of the details.

The third choice is the best in my opinion. It does require "widget Y," but it will only take a few days to implement. There are no cost savings, but the savings in the implementation time make up the difference. Read the attached document for the rest of the details.

Please let us know which choice you prefer.

A better example.

Dear CEO,

I have narrowed down the final choice for the "thing." I recommend the first choice because we can implement it within days and the cost is comparable to the other two choices. The other two choices take several weeks to months to implement and only save up to 5% after one or two years.

Do I have your approval to buy the first choice?

Deconstructing the two requests.

The first request is very long and lengthy. The engineer explains his task even though the CEO already knows it. This persons also brags about the amount of work invested. This person then proceeds to explain each choice in one paragraph. The leader does not learn about the best option until the end of the email.

The second request is only one paragraph. The engineer states the outcome in the first sentence and the recommended choice in the second sentence, and explains why the other two options were not as good in the third sentence. This person then asks a question that will lead to a yes/no response, or a request for additional information or a meeting.

The second request achieves in three sentences in what took four paragraphs in the first request.

What about the details?

As an engineer, I want to provide all the information and details about my analysis. Most engineers I know take pride in their work and get excited to share it. This does not mean we need to share all the details. We need to resist getting into all the details and get right to the point.

If our boss asks us to find the best widget, we return with the best one. If our boss asks us to discover why something failed, we present the most likely reasons. We share why as succinctly as possible.

Conclusion.

Getting to the point may be a difficult thing to do at first. We can fight the urge to share all the details by writing them down in a document. That document will be available to anyone who wants to know your processes, data, and findings. When it comes to communicating with others, present the outcome in one paragraph, in 30 seconds, or on one slide (depending on which medium you choose).

Before you go

About the author

Originally published on Patreon

Photo by Christina @ wocintechchat.com on Unsplash

How it works

We probably spend at least one to two hours using a web browser for personal reasons. Some of us probably use a web browser six to eight hours a day for work reasons. Even if we can earn five cents per hour when using a browser, we can donate at least $1 per month. That becomes $12 per year that we can donate by doing what we already do.

Introducing the Brave browser

The Brave browser allows us to do this. The browser is based on the Chromium browser. This is the same base that the Google Chrome browser uses. Anyone using Google Chrome would feel at home with the Brave browser.

The Brave browser was designed with privacy and speed in mind. It blocks trackers, ads, and other things that invade our privacy. As a result, web pages load faster.

Introducing Brave Rewards

To fund their development, Brave has a reward program. They anonymously serve ads as browser notifications. Whenever we get an ad notification, we are compensated with an amount of the Basic Attention Token (BAT) cryptocurrency. We can choose to exchange BAT for a fiat currency (e.g., USD), hold them until they appreciate in value, or spend them on a service that uses BAT.

We can also choose to contribute BAT to any Brave Creator. Brave Creators earn BAT whenever someone visits one of their websites, gets a tip, or receives a designated monthly contribution. A non-profit can start earning BAT when it registers as a Brave Creator, and Brave browser users contribute BAT.

Doing our part

We need to take some steps to start contributing BAT to a non-profit. We will review how to set up the Brave Browser, opting in for Brave Rewards, and setting up monthly BAT contributions.

We download the Brave browser from https://brave.com. We run the installer as we typically would on our operating system.

We are given the option to do a welcome tour which we can skip if desired.

We are also prompted to enable Brave Rewards. Once enabled, we can access the Brave Rewards settings by clicking the Brave Rewards icon to the address bar's right. We can also type brave://rewards/ into the address bar.

We click the Brave Rewards icon and click the "Rewards Settings" link.

We go to the Ads section and click the ads settings button.

We configure the settings per our preferences. (I chose to get the maximum number of ads.)

We can enable Auto-Contribute if we want to donate BAT to any Brave Creator website we visit. We are leaving this off so we can control how much BAT we donate and to whom.

We need to visit the Brave Creator's website to enable monthly contributions or give tips. For illustration purposes, we will use MiguelACallesMBA.com as an example.

When we visit a Brave Creator's website, we will see a checkmark on the Brave Rewards icon. When we click it, it will allow us to set up the monthly contribution or give tips. We do either or both, depending on our preferences.

We will see a "Verify Wallet" status on the Brave Rewards dropdown. We may safely ignore this if we plan to donate all your BAT. If we plan to use any of the BAT for other purposes, we will need to create an account on Uphold.com and connect it to Brave Rewards.

The non-profit's part

We must encourage a non-profit to become a Brave Creator and have an Uphold wallet for all this to work. They may be hesitant to accept cryptocurrency donations. We must help them understand this is similar to receiving other non-cash and asset donations (e.g., stocks, clothes, household items, and trusts). The BAT cryptocurrency is easily exchanged to a fiat currency (e.g., USD). They might also increase the donation's size if they hold it until it appreciates in value---although there is no guarantee that it will. We will review the process to become a Brave Creator.

The non-profit should first sign up at Uphold.com and create a business account. This step is important because they will be unable to convert BAT to a fiat currency without a valid Uphold wallet.

After they have a valid Uphold account, they sign up as Brave Creator. Once they create their Brave Creator account, they can link their Uphold wallet.

Now that they can receive BAT funds, they must create a channel to receive contributions and tips.

A channel can be a website, YouTube channel, Twitch channel, Twitter account, Vimeo channel, Reddit channel, and GitHub account. These are the channel types available at the time of this writing.

We should encourage them to enable as many channels as they have available.

Each channel type will require verifying ownership of the channel. For example, a website has two verification options.

Once verified, they can choose to enable the ability to serve ads. This possibility allows them to earn additional BAT from visitors who visit their channel.

Conclusion

We can use Brave Rewards to earn the Basic Attention Token (BAT) cryptocurrency while browsing the web using the Brave browser. We can donate BAT to our favorite non-profits when they enroll as a Brave Creator. The non-profits can convert BAT to a fiat currency (e.g., USD) or hold it until it appreciates in value.

Before you go

About the author

Originally published on MiguelACallesMBA.com

Photo by Kelly Sikkema on Unsplash

Script to Generate an Encrypted Secret

We can use a local Node.js script with the CryptoJS library to encrypt the secret. The example below shows how we will encrypt an API key.

const CryptoJS = require('crypto-js');
const { API_KEY: apiKey, SECRET_KEY: secretKey } = process.env;
const encryptedText = CryptoJS.AES.encrypt(apiKey, secretKey).toString();
console.log('encryptedText:', encryptedText);

We set the API key and secret key (used to encrypt the API key) as environment variables. That way we do not hardcode data into our script.

Using the Encrypted Secret and the Secret Key in Postman

We will store the secret key as a cookie to avoid sharing the value, and will store the encrypted API key as an environment variable.

We whitelist a cookie domain.

We create a cookie to store the secret key.

We create an environment variable that has the encrypted API key.

We create a pre-request script to get the secret key from the cookie, decrypt the encrypted API key from the environment variable, and set a temporary variable (Postman Sessions) with the plaintext API key.

// https://postman-quick-reference-guide.readthedocs.io/en/latest/libraries.html
const cookieJar = pm.cookies.jar();
const sessionVarName = "xApiKey";
const cookieName = "secretKey";
const domain = "postman.galaxy.demo";
cookieJar.get(domain, cookieName, (error, secretKey) => {
  if (error) {
    console.error(error);
    pm.variables.set(sessionVarName, "error");
  }
  if (secretKey) {
    // decryption
    console.log('secretKey', secretKey);
    const xApiKeyEnc = pm.environment.get('x-api-key-enc');
    console.log('xApiKeyEnc', xApiKeyEnc);
    const xApiKey = CryptoJS.AES.decrypt(xApiKeyEnc, secretKey).toString(CryptoJS.enc.Utf8);
    console.log('xApiKey', xApiKey);
    pm.variables.set(sessionVarName, xApiKey);
  } else {
    console.error("Cookie is missing")
    pm.variables.set(sessionVarName, "missing");
  }
});

We write a test to explicitly delete the xApiKey variable after the request completes.

pm.variables.unset("xApiKey");

We can use the xApiKey variable to use the plaintext API key.

Conclusion

By using cookies, we can use a secret key while avoiding sharing it. By using CryptoJS, we can store encrypted data in an environment variable, decrypt it, and use the plaintext (i.e., decrypted) data only during the request execution.

Before you go

About the author

Photo by Food Photographer | Jennifer Pallian on Unsplash

Guessing An Email Address

Guessing an email address can be easy. We can guess an email address by trying any of the following:

• FirstInitialLastName@gmail.com
• FirstNameLastName@gmail.com
• FirstName.LastName@gmail.com

What is the chance you have this email address?

Social Media Accounts

We often post too much information on social media accounts. We post our name, location, recent activity, links, and more. Someone can use this information to deduce information. They can guess an email address, figure out security questions, or even take it over. We are making it easier for someone to guess our email address.

Taking Advantage of Email Tags

We can be in big trouble if our important accounts use the guessable address. We can reduce this exposure by using email tags. We can sign up to a bank website with the email FirstName.LastName+SomeUniqueTag@gmail.com. Many email providers and online accounts support this capability.

Taking Advantage of Many Addresses

Services like Gmail make having many addresses cost-effective. We can have a different email address for a different purpose.

• FirstName.LastName@gmail.com for emailing friends and family.
• FirstName.LastName.DesiredJobTitle@gmail.com for job hunting and resumes.
• FunPseudoNameOrHandle@gmail.com for non-important accounts.
• SeriousPseudoNameOrHandle@gmail.com for important accounts.
• AnotherSeriousPseudoNameOrHandle@gmail.com for your password manager.

Make sure you use a "PseudoNameOrHandle" that someone cannot guess.

You may also use email tags to make it more difficult to guess the email address. For example, using a SeriousPseudoNameOrHandle+UniqueTag@gmail.com convention per account.

Has Your Email Address Been Leaked?

You should check whether your email address has been leaked. You can use Have I Been Pwned to check all your email addresses. Create a new email address and start moving your accounts to that email address if you have been Pwned.

Conclusion

Using different email addresses as a cybersecurity strategy can reduce our risk. But make sure to follow good security hygiene. Use a strong, unique password for each account. Enable two-factor/multi-factor authentication. Update your passwords regularly. Also, check all those email accounts to avoid missing important messages.

Before you go

About the author

Originally published on Secjuice.com

Photo by Przemyslaw Kruk on Behance

There are many good stocks and finding them takes time. We can find them by reading articles, using stock tools, getting tips from Twitter, and many other ways. With so many ways to find stock candidates, we needed to define the process.

Finding a Screener

We decided FinViz.com was a good source to start our automation. One of our team members is a good stock analyst. He created a screener that we used for a long while.

Example FinViz Screener

Creating a Web Scraper

After a while, we noticed we were forgetting to check this screener. That is when automation became handy. I wrote a Python web scraper using BeautifulSoup to get the top 10 stock symbols from the screener.

import requests
from bs4 import BeautifulSoup

FINVIZ_BASE = "https://finviz.com"
FINVIZ_PATH = os.environ.get('FINVIZ_PATH')
FINVIZ_DATA = {}
FINVIZ_HEADERS = {
    'User-Agent': 'My Trading App/0.0.1'
}

response = requests.get(
    f'{FINVIZ_BASE}{FINVIZ_PATH}',
    headers=FINVIZ_HEADERS,
    data=FINVIZ_DATA
)

soup = BeautifulSoup(response.text.encode('utf8'), 'html.parser')

## look for symbols
for link in soup.find_all('a'):
    if link.get('href').startswith('quote.ashx?t='):
        symbol = link.string
        if symbol:
            ## assumes this html code
            ## <a class="tab-link" href="quote.ashx?t=TWTR&amp;ty=c&amp;p=d&amp;b=1">TWTR</a>
            symbols.append(symbol)

I needed a way to run this web scraper on a timer. I could have set up a server to run the Python code on a CRON, but I did not want to maintain the server. I decided to use a serverless solution to reduce maintenance and keep my costs low.

I set up an AWS Lambda function with a Python runtime, and deployed it using AWS CDK. I configured CloudWatch rules to set up a CRON to trigger the Lambda function. Now the web scraper runs per the schedule.

Posting to Slack

We were already using Slack to chat, so it was the ideal medium to post the top ten symbols. I created a Slack app that posted the findings to an #alerts channel and the #general channel. The #alert channel posts had detailed information (e.g., chart images). The #general channel posts had the summary information. We did this to not overwhelm the discussion in the #general channel.

Example of the #alert channel post.

Example of the #general channel post.

Creating stats

As you might have guessed, it became difficult to see patterns without some type of stats. We had good intel, but how do we decide which stocks to pick without some type of histogram.

We wrote the stock symbols to a DynamoDB table, and the date when they appeared in the alert.

import boto3

STATS_TABLE_NAME = os.environ.get('STATS_TABLE_NAME')
STATS_TTL_NAME = os.environ.get('STATS_TTL_NAME')
STATS_TTL_DAYS = int(os.environ.get('STATS_TTL_DAYS')

client = boto3.client('dynamodb')

for symbol in symbols:
    client.update_item(
        TableName=STATS_TABLE_NAME,
        Key={
            'PK': {
                'S': symbol,
            },
            'SK': {
                'S': f'#{sk_prefix}#',
            },
        },
        AttributeUpdates={
            STATS_TTL_NAME: {
                'Value': {
                   'N': f'{ttl}'
                },
                'Action': 'PUT',
            },
            scan_name: {
                'Value': {
                   'BOOL': True,
                },
                'Action': 'PUT',
            },
        },
    )

We then created another Lambda function to post a text-based histogram.

Example histogram post to the #general channel.

Conclusion

With a little code we implemented automation to our manual investment process. We were able to extend this approach to scrape different investment sources. Furthermore, it costs $0.00 per month by taking advantage of the serverless capabilities in the AWS free tier.

Before you go

About the author

Disclaimer: This is NOT investment advice.

Photo by William Iven on Unsplash

Do your serverless deployments go like this?

It’s so easy to quickly deploy serverless resources. Because of this, we should follow best practices to protect our resources, applications, and cloud service provider accounts. Here are some best practices for you to consider.

1. Keep Functions Small

A serverless function should perform a specific function. Similar to a function or method in any code should do one thing (e.g., increment a counter, transform data, etc.), a serverless function show perform a logical function. For example, you would create one serverless function for validating a login, another for validating a login session, another for deactivating a login session. Having a serverless function perform more than one thing makes it vulnerable to bugs and makes it more difficult to maintain.

2. Organize Functions in a Group (i.e., Use Microservices)

Microservices allows us to contain data stores and functions into a maintainable group. The microservice will follow a contract that limits what it can and cannot do. For example, an account microservice will allow creating, updating, and deleting user accounts. This microservice should never modify any data outside of the user account data store. Furthermore, it will have a specific application programming interface (API). This allows other microservices to interact with the user account serverless functions in a consistent way without having to modify any of its user account data stores.

3. Use Different Stacks for Different Resources

AWS allows us to use CloudFormation stacks when deploying resources, and each Serverless Framework configuration deploys one CloudFormation stacks. We should aim to have one stack per resource type. For example, our user account microservice could have: database stack (to store account metadata in DynamoDB), identity provider (IdP) stack (to set up and maintain user sessions with Cognito), function stack (to deploy Lambda functions that provide the user account microservice API), and object store stack (to capture user account profile pictures in S3). This allows you to update a resource type without disrupting another resource type. For example, if you make an error in a functions stack deployment, your other stacks remain unaffected.

4. Select an Appropriate API

AWS offers three types of APIs: HTTP APIs, REST APIs, and GraphQL APIs. Each API has different benefits. HTTP APIs use API Gateway, are lightweight and natively support OpenID and OAuth. REST APIs use API Gateway, are fully featured REST APIs and provide additional security features. GraphQL APIs use AppSync, use a simple, but string query language, and integrates with DynamoDB databases and Elasticsearch Service data aggregator. API Gateway HTTP and REST APIs are best for interactions between APIs (or microservices) and providing external applications access to your applications API. AppSync GraphQL APIs are best between client and backend integrations within the same application (of course your client can still use an API Gateway API too.)

5. Use the Principle of Least Privilege in Your Serverless Functions

All your resources should have the smallest set of IAM permissions. For example, a serverless function that reads a DynamoDB table should only have the read action for that one DynamoDB table. You should avoid using an asterisk “*” when defining privileges whenever possible. If you Lambda function is ever compromised and it uses asterisks such that every DynamoDB is accessible and every action is allowed, then a hacker can read and delete all database data.

6. Set up a CI/CD Pipeline

When you are first developing an application, deploying from the command line interface (CLI) is okay. Ideally before you get to deploying to production, you should be using a CI/CD pipeline to deploy your code. You can use services such as Serverless Framework Pro, GitHub Actions, SEED, and many others. CI part of the pipeline allows you to run linting checks, unit tests, and many other automated checks before allowing a pull request to merge. The CD part of the pipeline allows you to automatically deploy your serverless application whenever a PR is merged or a branch is updated. Using a CI/CD pipelines removes human error and introduces repeatability in your process.

7. Monitor Your Application

We should use services, such as Dashbird, to monitor our serverless resources. There may be so many resources and they may be used so much that it would be difficult to manually check them for errors. Monitoring services can report health, longer executions, delays, and errors. Having a service that tells us when our serverless application and resources are having issues helps us to find and fix issues faster.

8. Audit Your Cloud Provider Account and Resources

In addition to monitoring, we want to audit. Monitoring tells when when something stops working or is having issues. Auditing tells us when our resources deviate from a known configuration or are improperly configured. We can use services such as AWS Config to create rules that audit our resources and their configurations. Config also has some predefined conformance packs that help us implement best practices. Here are some to consider:

• Operational Best Practices for Amazon DynamoDB
• Operational Best Practices for Amazon S3
• Operational Best Practices for AWS Identity And Access Management
• Operational Best Practices for AWS Well-Architected Framework Reliability Pillar
• Operational Best Practices for AWS Well-Architected Framework Security Pillar
• Operational Best Practices for Serverless

9. Audit Your Software Dependencies

We also want to audit our software dependencies. Just because we no longer have a server, it does not mean we are free from “patching.” We want to make sure any software dependencies we define are up-to-date and have no known vulnerabilities. We can use services such as GitHub Dependabot and Snyk to keep us informed the software packages that need updating.

Conclusion

Your mileage will vary depending on your business and technical requirements, the complexity of your application, and your cost and schedule. These best practices are aimed to guide in the right direction; they are based on the “Serverless Security” book.

Before you go

About the author

Originally published on Medium.com

Photo by Sarah Kilian on Unsplash

A couple of days ago, I received a notification from the Microsoft Edge browser warning me about malware in one of my extensions: The Great Suspender.

I started panicking, so I decided I would start researching this. I found the GitHub repository for The Great Suspender extension. I searched for “malware” in the open issues and surprisingly found a relevant issue.

SECURITY: New maintainer is probably malicious

Here are a couple of snippets from the issue that increased my concerns.

On November 6th, @lucasdf discovered a smoking gun that the new maintainer is malicious.

Using the chrome web store version of this extension, without disabling tracking, will execute code from an untrusted third-party on your computer, with the power to modify any and all websites that you see.

I have been running anti-malware software and running scans daily, and there were no reports of malware. It occurred to me that anti-virus and anti-malware might only catch malware running on the machine.

Fortunately, I have been running the Malwarebytes browser extension for a few months. I hope this helped mitigate some of the issues, yet the malware might have been present since November 2019 (that more than one year ago at the time of this writing).

My actions steps

I started to take action right away.

• I uninstalled the extension from the Microsoft Edge browser. Edge had already disabled it for me and no longer allows anyone to install it.
• I uninstalled the extension from the Chrome browser. I also reported abuse since Chrome still allows anyone to install it.
• I fully cleaned my browsers by clearing the all-time history, cache, etc.
• I ran CCleaner to do a full cache clean on my machine.
• I installed another anti-virus program and ran a full, deep scan just if my anti-malware program missed anything.
• I started to changed passwords to my sensitive accounts.
• I revisited my browser extension preferences, which I will discuss in further detail.

From what I can tell, there is no breach. I hope it stays that way.

Updated browser extension preferences

I did the following to improve my browser extensions:

• I updated all the remaining extensions by visiting Manage Extensions, enabling Developer Mode, and performing an Update.

• I checked the extension permissions and realized I was giving the “keys of the kingdom” to all my extensions, so I put that to an end.

• I visited each of the extension preferences, navigated to This Can Read and Change Site Data, and set the permission to When You Click the Extension. I implemented this setting to all extensions except those meant to “protect” me, such as the Malwarebytes Browser Guard extension. Note: The screen capture below shows the restricted setting for illustration purposes.

Now, when I want to use an extension, I need to activate it.

The extension is currently disabled.

It is somewhat of an inconvenience. Yet, I still benefit from the extension only when I want to use it instead of when the extension wants to do something.

Conclusion

Decide whether it makes sense to install a browser extension, whether you can trust it, and how much of your data you are willing to give away.

Consider implementing the extension settings I showed above, and visit sensitive web sites (e.g., banking sites) using Incognito Mode.

Before you go

About the author

Originally published on Medium.com

Photo by Michael Geiger on Unsplash

Recommendation for powering an Amazon FireTV Device

Amazon Fire TV devices are pretty nice, but there is the risk they listen to you. In this super short article, I will share how you can minimize the amount of time this device (or a similar device) can listen to you.

1. Buy an eco-friendly power strip that controls other outlets.
2. Connect your TV to the master (or control) outlet. This outlet will control when power is delivered to the dependant (or energy saving) outlets.
3. Connect your Fire TV (or similar device) to the dependant outlet.

Now the Fire TV will only power on when you are watching TV.

BONUS #1: You can unplug the Fire TV USB port when you’re done watching and reconnect it when you want to watch. I suggest doing this because you may not always use your Fire TV when you watch TV. Surprisingly, I still use DVDs and Bluray discs.

BONUS #2: Connect your Fire TV to your router’s guest network instead of your main network. Configure the guest network not to have access to the main network. If the Fire TV ever gets hacked, the hacker will not have access to your main network.

I hope this helps you improve your home’s privacy and cybersecurity.

Before you go

About the author

Originally published on Medium.com

Photo by Jason Rosewell on Unsplash

Serverless environments allow you to build applications without needing to manage and use servers. They allow you to upload your code without worrying about how to configure a server, installing the runtime environment, applying patches, setting up the networking, and identifying all the other tasks needed to run said code. Sounds too good to be true? Wait, there’s more!

Serverless environments can potentially reduce your application’s attack surface. We will compare a traditional application’s attack surface against that one running in a serverless environment.

Traditional Application’s Attack Surface

Let’s suppose you have a web application you set up on traditional servers. This application has servers dedicated to running the web application code and other servers running the database. These servers are running in the same subnet somewhere, which could be in your own facilities or in a cloud provider. The application and web servers are configured to communicate with each other.

They run the same type and version of an operating system, a specific version of a software runtime, and a particular version of the database. Now that we have established the application’s components, we can proceed to identify the attack surface. The attack surface is the accumulation of all known and unknown vulnerabilities that can be exploited. Each vulnerability can happen at all levels of the application stack. Let’s proceed to identify potential vulnerabilities:

• An operating system has unpatched software with vulnerabilities.
• An operating system is missing security settings (e.g., no firewall).
• An operating system is lacking proper account management.
• Using an operating system that is end-of-life.
• Using a software runtime that is end-of-life.
• Using a software runtime with known vulnerabilities.
• Running the software runtime without account restrictions.
• Using software libraries or packages with vulnerabilities.
• Improperly configuring the database.
• Giving the database full Internet connectivity.
• And there is a lot more.

As you can see, the application attack surface can be more significant, especially when security was not a priority when building the application.

How Serverless Can Reduce The Attack Surface

Using a serverless environment can reduce the attack surface. We would only need to focus on the topmost application layer in the OSI model. But, how can serverless reduce the attack surface? Let’s look at the previously identified vulnerabilities and see how serverless can reduce or eliminate them.

• An operating system has unpatched software with vulnerabilities. The cloud provider is responsible for patching the infrastructure and does it periodically.
• An operating system is missing security settings (e.g., no firewall). The cloud provider is responsible for securely configuring the infrastructure with the proper security settings to protect itself.
• An operating system is lacking proper account management. The cloud provider is responsible for setting up the proper account management for the infrastructure.
• Using an operating system that is end-of-life. The cloud provider is responsible for ensuring it only uses currently supported operating systems.
• Using a software runtime that is end-of-life. The cloud provider is responsible for ensuring it only uses currently supported software runtimes.
• Using a software runtime with known vulnerabilities. The cloud provider is responsible for keeping the software runtime up-to-date.
• Running the software runtime without account restrictions. The cloud provider is responsible for securely configuring the software run time.
• Using software libraries or packages with vulnerabilities. The developer is responsible for auditing the software libraries and packages.
• Improperly configuring the database. The cloud provider is responsible for securely configuring the database.
• Giving the database full Internet connectivity. The cloud provider is responsible for securely configuring network connectivity.
• And there is a lot more.

As you may have noticed, we offloaded our security configuration, maintenance, and risks to the cloud provider for all but one vulnerability.

Serverless is not a silver bullet or a golden gun.

Serverless comes with its own risks. The Open Web Application Security Project (OWASP) publishes the OWASP Serverless Top Ten that identifies the topmost security risks in serverless applications. Like with any application, it can be more or less vulnerable depending on the architecture, design, implementation, use, and maintenance. This post highlights how serverless can potentially reduce your application’s attack surface, especially if you do not have security expertise, time, or resources to deploy a secure application.

Before you go

About the author

Originally published on Secjuice.com

Photo by Damir Spanic on Unsplash