For this Serverless Podcast, Hillel was joined by Shali Mor, Vice President, R&D and Co-founder of Protego.

Watch the video below or listen to the audio on SoundCloud.

Shali explained, “In R&D, we focus on 3 main things:

  1. Providing value to customers. Serverless security can be time-consuming and difficult, and we aim to alleviate the headache of customers doing it themselves
  2. Follow strict regulations to ensure metadata is safe in our back-end
  3. Making sure our product can work at scale.”

Hillel and Shali were also joined by Chris Ensey, COO of Riot Blockchain. Previously, Chris was COO of Dunbar Security Solutions where he managed over 150 security professionals across physical and digital operations doing global threat monitoring and management. Prior roles include Director of Government Solutions at SafeNet, Principal Security Strategist for IBM’s federal division, and supported software development projects for the US Department of Defense.

Chris stated, “At Riot, what we do is related to the blockchain, the things we work on are 3 areas:

  1. Invest in privately-held companies that are building new tech leveraging blockchain
  2. Operate a massive cryptocurrency mine
  3. Evaluating an entry into the cryptocurrency exchange market.”

The Great Serverless Comprehension Divide

The first topic of conversation was serverless adoption. When does it hit mainstream? Making that distinction is difficult, considering many large companies are doing things with serverless and have been for over a year, although it’s still early days of adoption. One article from Calcalist asserted that mainstream, large-scale adoption is emerging now.

A Digital Ocean report stated that half of developers don’t think they know serverless well enough, while the other half know it well, and over one-third have deployed serverless apps.

The Challenges and Benefits of Serverless

Shali stated, “We do serverless because we protect it, it makes sense that we need to know what we are doing. But regardless of that, I worked at different, big projects where I was responsible for doing the orchestration myself. I used tools like Kubernetes and Mesos tech marathon and it wasn’t very easy to do that orchestration and monitoring part. The first thing I found very beneficial with serverless is that you don’t really need to do the ops. No infrastructure is involved, and you get it out of the box.

“The second is that I’m a big fan of agility. I like doing things fast. Using serverless and a function mindset is something that enables you to rapidly change the code and redeploy, and that’s something we find very beneficial.

“One downside is that the debugging and monitoring tools are not mature enough, although I think it will improve in the future. Another downside is some parts of the entire cloud infrastructure are not pure serverless, which don’t work as expected and slow us down.”

In response, Hillel fessed up, “I take full responsibility for driving you guys crazy with changing requirements, and serverless has certainly helped us meet some of my craziness, and so that’s good. And I concur that we suffer from the things that aren’t yet as serverless as they need to be.”

What Changes in Serverless?

There’s a constant stream of headlines of people trying to understand or educate others regarding what changes when you move to serverless. Today the group discussed, “Why Serverless Needs DevOps.” Hillel stated, “It’s not the reality that serverless leads to ‘NoOps’ and you don’t have to operate anything. It’s true that the operations overhead drops a lot. We’ve spoken with organizations that moved to serverless to save money on compute, but it turned out the big savings came from shifting operations people to development.

“Operations changes, and the overhead is reduced, although it doesn’t disappear. In the post serverless world, ops is more focused on creating pipelines that let developers work at the speed of serverless and still deploy things in a sane way.”

A Network World article with the great, catchy title, “Solving for serverless: How do you manage something that’s not there?” stated one of the big things that changes is how you monitor and what you’re looking for in security. How do you know that something bad happened, and you need to react and what you need to be looking at?

What’s the Role of DevOps and DevSecOps?

Chris responded, “I have a feeling this is a fiery topic for a lot of people. I don’t want to catch the ire of the community when I start talking. We’re at a transition point, going from traditional security operations center model where we have a massive amount of data flow and looking at archaic, siloed systems, as we do the monitoring and try to find issues we can start to tackle and react to, to a model where we’re integrating security into the process of rolling out new apps, then maintaining and managing them. Then transitioning to an evolution where we look at it on a functional level. I don’t think it’s different, just an evolution as these things become autonomous in a certain way.

“Now we have to change the mentality of how you manage it. There is going to be serious upheaval in how we do our day to day function in SecOps in the place where there’s little infrastructure to monitor and it’s just going to be event driven. We’re going to have to spot trends and look for standard deviations in a flow of activity. It will be heavily behavioral driven and will change how we train people to operate in that environment. It’s going to be a big shift, and we’re going to have to have more collaboration and engagement. Connecting the dots between organizational structures is a piece where orgs will have the biggest hurdle.

“With serverless, you’ll see an even bigger push to drive faster and further to get all these things tied together and integrated, so it doesn’t just generate poor-value, noisy data, but valuable, actionable alerts.”

Hillel replied, “Very often in serverless the amount of data is greater, but making sense of it is more challenging because it’s more fine-grained and doesn’t mean anything on its own. Finding context is always important.

“I’ve been hearing the argument that security should just move over to become the responsibility of developers. I personally find that a difficult position to put the organization in. I don’t think that will ultimately drive higher levels of security. It’s really challenging to expect developers, who are doing their very fast-paced day job of building things, to also be limiting and figuring out how to prevent things from happening. The other end of the continuum is to just keep doing things from the perimeter and monitoring without the developers, and I’m having trouble believing that’s going to work where things are a lot more code-driven and remediation might happen often in developers’ hands.

“We’re looking at a model in the middle, where security owns security, but developers have to be a bigger part of the solution. At Protego, we’re working to get the right info in the hands of the right person in the right workflow all the time.”

Chris added, “It’s also a quality issue. You can’t expect developed code today to last in a future view to retain its security. It will always be changing and evolving. You can never be in a position where developers will exclusively own that. To task them to maintain security ongoing is going to be a complete fail.”

The Challenges of Operating a Cloud Native App at Scale

Shali commented on the challenges of operating cloud native apps at scale. “DynamoDB, for example, has its limitations. Scaling isn’t something that can be done zero to 100 in one second. It might take five minutes for the system to understand that it needs to scale up. Another example would be AWS APIs are limited to a certain amount of calls per minute.

“To cope with that, you have to reduce the load at your backend. You have to scale gradually, which is a big effort. I think eventually all services will move in that direction, and provide immediate scale.”

Tweets of the Week

Hillel selected a tweet from Simon Wardley, in which he humorously makes the point that there’s a lot of confusion around what serverless really means and what cloud native really is. Many people trying to redefine things they’ve been doing for a thousand years as serverless. Movable type is serverless. Let’s stick to the actual values serverless brings and stop redefining everything we’ve ever done in a VM as serverless.

Chris selected a story from The Verge about a new application that allows you to create entire websites solely within a URL. You can take the content of the website, including the HTML, imagery, formatting, etc. and self-contain it into the encoded URL itself. It’s microsites- and serverless-oriented and doesn’t require any real server to run it. It all happens in the browser as you load this URL. I think this presents some interesting opportunities, both from the user side and the attacker side.

“As an attacker, I would look at this as a great tool. It could enable a phishing campaign or be a way to bypass a firewall or web filtering solution very quickly. There are probably a million different ways to spin this and I’m excited to see what happens next,” stated Chris.

The Shodan of open S3 buckets. has created a nice little search engine, similar to Shodan. There’s a way to browse S3 buckets and to categorize the content and there are thousands of these buckets available. Shodan exists not necessarily to be used as an exploit tool, but to give an open eye to what’s going on, and the problems that exists with transparency and availability of S3 buckets.

“I think there will be more application to building serverless discovery tools that can open the eyes of a perimeter investigator. There are tools like Protego that are evaluating the infrastructure being built. Realistically, I think the community that’s looking for open source intelligence on how to evaluate the security of a potential target will take these tools and run with them,” concluded Chris.

Shali selected a tweet from Laura Martin quoting Erica Windisch at Serverless Days London. He explained, “All developers faced that in the past. When you hit an issue, you go ahead and code it. Even if it is time-consuming, you think that’s the best solution because you did the job. And I think that has to change. Currently, if you need to do something, see if it’s out there, if someone already did it. So serverless is a concept which means you can concentrate on what exactly you need to do. All other things, try to get somewhere else.”

Share This Article
Share on facebook
Share on linkedin
Share on twitter
Share on email

Join industry experts as they discuss all things serverless including industry news and best practice tips.