Cybersecurity Skills Gap Soars as Brexit Bites – Infosecurity Magazine
“The cybersecurity talent gap is greater than for any other digital skills, according to new research from…”
Reading articles like these have me becoming more and more skeptical. The article is meant to push the narrative that more skilled security people are needed in the industry. I wonder how many working in the industry agree with this narrative. Sure, there are a bunch of security jobs out there, but are they for companies that are serious about security and want to improve their security posture? Every C-level executive is looking at the IT department as a cost center and the security team as the cost center of that cost center.
I don’t have the resources and the time to do an official study, but I think most would agree that security teams have grown by percentage of IT staff over the last 20 years. That situation cannot continue on forever; something has to be done about it. Everyone is looking for three things to right the ship: More efficient security tools, transfer of security risk, and better configuration management.
Firstly, more efficient security tools are not a new dream. Vendors and security teams have been after this for a while. The reality is vendor after vendor just seem to suck. The products are not consistent in their effectiveness. Bigger companies have had their security teams delivering tons and tons of code to internal tools and processes. This has gone on year after year and we still haven’t gotten anywhere. Why?
With SecAI just around the corner for mainstream use, the security tools should be getting augmented effectively very soon. A SecAI discussion is another article for another time.
Secondly, the transfer of security risk is a big deal right now. If you’re smaller than AWS, Azure, or Google than start transferring security risk to them. Don’t give me that, “we want to control our own security” garbage. Those companies have huge security teams. You’re never going to be able to keep up with them, and the number of attacks that they’ve seen and remediate are always going to be more than your team, so just give up. Especially, on the network edge, services like Cloudflare are going to keep you focusing on things that matter directly to your company. Right now, this might be the biggest surge in securing assets we’ve ever seen globally.
Thirdly, configuration management is getting better and more affordable. This is taking on many different forms like containers and immutable servers. Orchestration tools have been around for a long time, but those companies that built them were greedy and wanted too much money for them. And they weren’t the greatest tools anyways with out an army to run them. Do you see the irony there? If have to run them with an army, are they really helping you?
If you’re aren’t using tools like Docker, Puppet, or Chef, then you need to be researching them. They are going to provide huge releases of pressure on all IT teams. The biggest issue is just culture. We need to use them effectively and force crappy commercial software vendors to write for them or go out of business.
Put your own timeline on each of these prongs of attack: better tools, transfer of risk, and configuration management improvements. This is what leadership is looking at to fix our budget and security issues; not more staff or more skilled staff. They can’t afford either of those anyways. In the next few years there will be a sizable loss of staff positions in those areas directly affected by those improvements.
This article is a quick, extremely high level, view of what serverless architecture is and what it brings to the table. Since this article is geared for upper management, it is focused on relaying the impacts to various teams within a typical IT organization. Finally, this is a call to arms for senior staff to engage in serverless projects.
Intro (What is serverless Arch? FaaS)
This isn’t the first article about serverless by any means. However, in this article, we’re going to touch on a couple aspects that hopefully provide new content. We’ll be discussing whether serverless is ready for primetime or not and the impact this technology will have on some key persons in IT departments.
So, let’s start with a quick intro into what “serverless” really means. Serverless is also known as Function as a Service (FaaS). The service or concept centers around the idea of building blocks of code and chaining them together with the intention of using cloud services solely and without the use of a server that the customer maintains. Behind the scenes there are servers, but to the customer it’s completely serverless.
I feel like this will have a much bigger impact on computing than virtual machines did. Let’s take a look at some of the benefits:
No operating system to upgrade.
No more running antivirus everywhere.
No more system patches.
No more aggregating many diverse logging sources into one repository.
No more rogue administrators installing software on random servers, because they can.
No more scaling resources vertically.
No more paying for computing resources when they’re not in use.
Is it ready for primetime?
So, one of the questions you’re probably asking is whether this is ready for primetime. How many services have we been told are ready for “general release” only to find out that they’re not really ready for primetime? We’ve heard tons of hype around other technologies and paradigm shifts in the past and many turn out to be just a fad. We’ve all looked at Gartner Hype Cycles to see where we are with a given technology. Well, at this last AWS re:Invent conference (2016) in Las Vegas, we heard several companies doing serverless systems. Vice President of Engineering, Theresa Sage from McGraw Hill gave a presentation about how her company built a mission critical system entirely serverless (Feldon & Sage, 2016). Coca-Cola and Netflix were amongst some of the other giants giving talks on their serverless systems. It seems to be clearly on the roadmap for many companies and they aren’t shying away from relying on this infrastructure for critical services.
Impact for Ops teams
These teams are uniquely geared for work through each layer of the OSI model. This gives them a clear understanding of how these service interact and how best to build a serverless infrastructure. The new era of DevOps and SecDevOps will look to bring these teams closer together and they will mechanically work through deployments of new applications and services. Operations teams typically don’t grow much, if at all, but the computation and storage requirements, that they are responsible for, doubles every 5-10 years at a normal company. They must always get faster and more efficient, but there will always be an operational team even if we call them something new.
Impact for Developers
Developers are going to have huge changes. Developers have been after the holy grail of decoupled code and near infinite scaling, for a long time now. They have been constrained by the OS+server combo they’re running on, but no longer. Critics are going to argue that these walls prevented bad code from getting deployed until the developer made it more efficient. I want to point out that there’s also a bunch of good code that couldn’t be deployed, because of these constraints too.
Developers are going to have to decide how they want their career to progress from here, because you will literally be developing something that will only run in one cloud environment. It’s no longer portable. Some cloud skills will be gained from learning microservices and such, but the low level details will be point-in-time knowledge. Developers are already nervous about the wholesale abandonment of a philosophy of coding, but this is the evolution.
The power of coding this way and really accepting DevOps as a model is going to leave your competitors in the dust. We’ll be taking away some power from the developers, but this is secretly what they want anyways. They may complain that they can no longer login to the server and look at it running, etc. They may not have said it out loud to themselves, but they don’t want that ability anyways. They just want to write code and have it run without worrying about the OS or anything else that may dirty up their perfect application.
There are some subtle things that they need to learn when designing serverless infrastructure. I highly recommend a talk from 2016 Re:Invent on Serverless Apps with AWS Step Functions. https://www.youtube.com/watch?v=75MRve4nv8s&t=1404s Tim Bray, Senior Principal Engineer gives a great presentation on how to keep state and build applications that can scale really well.
Impact for CIOs
So, what’s the impact of serverless architecture on CIOs? We’ll not much at first look. Each organization will have a different needs, budgets, and success criteria. CIO’s need to take a hard look at this design, because it should really drive much of their decisions. Pursuing cloud and serverless is going to force reorganizing teams and workflows. If you’re in the private industry you’re going to want to be agile and aggressive in changes to customer demand. If you’re in the public sector you’re going to need to move to OPEX and really drive your team’s efficiency.
I know what you’re thinking, “So, what? This is no different than the last 10 or 20 years.” If you’re a CIO you must hear me right now. You will need to make an exponential gain in these areas over the next 5-7 years, because everyone else is. If you’re in the private world, you will be left behind if you don’t have a bunch of infrastructure that keeps you competitive. If you’re in the public sector, the pressures from legislature and your leaders are going to get extreme and you will need to justify your existence if you aren’t really aggressively pursuing these advantages.
Now, for some of the nuts and bolts. Your teams are going to have a culture shock. You will need to force their adoption of some components. Don’t be surprised if your first few projects look like train-wrecks. Everyone, will need to get through a couple to figure out how to do it right. Also, be prepared for statements like, “We need to burn down the environment, so we can build it better.” This is common and make sure you embrace it. The faster your team can identify these mistakes and correct them, the better, and because it’s in the cloud and not on premise they can do this work much more efficiently than ever before.
A big piece to add to this is that depending on your size and sector you should really look at adding big data scientists to the lineup. You will have all the data that you need, but to get the business intelligence out of it, you’ll need to put focus on that. Setting the vision and philosophy ahead of time, with this component in mind, will go a long way in helping those teams to dig out the gold nuggets.
Impact for Security teams
Holy crap! Security teams have just been given a pandora’s box. Half the time they don’t know whether to be scarred or ecstatic. They now how have all the vision, control, and tools they need. However, they have crazy things like a checkbox that can expose files to the Internet to worry about. Really, security teams need to go figure out all there is to know about the cloud so they can put in the proper technical controls ahead of time. Security processes are going to take a big hit, and these teams must figure out how to fit the new code pipelines; many changes per day; and automated everything, into their processes or they will be left behind. I think security teams will see massive push back from other teams if they aren’t as agile as the rest of the organization.
That’s just cloud, but now serverless puts them into an interesting spot. There is no OS to attack, there’s no antivirus to run, there’s no more refreshing OS’s, etc. The obvious thing is that there is a smaller attack surface. This doesn’t mean that there is no threat, but it’s moved up the stack a bit. This will lead back to the big data people I was talking about earlier, you need to work out serious analysis to determine anomalous behavior within the application.
The new architecture is going to blur the traditional lines between teams. IT shops that are still living in the dark ages of, separate siloed teams based on function, are going to have one of several outcomes:
They’ll be outsourced as they become more and more inefficient, the cost saving of outsourcing many of their functions will start to look appealing to the bean counters.
They will refit themselves based on the new DevSecOps philosophy. This will come at great cost and the longer it takes to cutover the more costly it will be.
The organisation will fail or be absorbed by another. If it’s a small business they will lack the competitive advantages and succumb to their rivals. If they’re a government org, they will be absorbed into a parent agency either in whole or just the IT staff.
For those managers and senior staff reading this article, if you haven’t looked at serverless yet, you are behind. Don’t waste time looking for someone who has it all figured out; they aren’t out there. Get your teams working on the philosophies and work out for your organization what you can get put into this architecture. Push them to do it and prepare for mistakes and rebuilding. Once they get through one of those projects they’ll have learned a lot and will have momentum for the next project. So, start by looking through the references section of this article and get after it.
(2016, December 02). AWS re:Invent 2016: NEW LAUNCH! Serverless Apps with AWS Step Functions (SVR201). Retrieved February 20, 2017, from https://www.youtube.com/watch?v=75MRve4nv8s&t=1404s
Event Handling at Scale: Designing an Auditable Ingestion and Persistence Architecture for 10K events/second. (n.d.). Retrieved February 20, 2017, from https://www.portal.reinvent.awsevents.com/connect/sessionDetail.ww?SESSION_ID=8955
The Serverless Application Framework powered by AWS Lambda and API Gateway. (n.d.). Retrieved February 20, 2017, from https://serverless.com/
Serverless computing. (2017, February 05). Retrieved February 20, 2017, from https://en.wikipedia.org/wiki/Serverless_computing
Wiggins, A. (n.d.). The Twelve-Factor App. Retrieved February 20, 2017, from https://12factor.net/